home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc916.txt < prev    next >
Text File  |  1994-08-01  |  111KB  |  3,079 lines
  1.  
  2.  
  3. Network Working Group                                            G. Finn
  4. Request for Comments: 916                                            ISI
  5.                                                             October 1984
  6.  
  7.              RELIABLE ASYNCHRONOUS TRANSFER PROTOCOL (RATP)
  8.  
  9.  
  10. Status of This Memo
  11.  
  12.    This RFC suggests a proposed protocol for the ARPA-Internet
  13.    community, and requests discussion and suggestions for improvements.
  14.    Distribution of this memo is unlimited.
  15.  
  16.    This paper proposes and specifies a protocol which allows two
  17.    programs to reliably communicate over a communication link.  It
  18.    ensures that the data entering one end of the link if received
  19.    arrives at the other end intact and unaltered.  The protocol, named
  20.    RATP, is designed to operate over a full duplex point-to-point
  21.    connection.  It contains some features which tailor it to the RS-232
  22.    links now in common use.
  23.  
  24. Introduction
  25.  
  26.    We are witnessing today an explosive growth in the small or personal
  27.    computer market.  Such inexpensive computers are not normally
  28.    connected to a computer network.  They are most likely stand-alone
  29.    devices.  But virtually all of them have an RS-232 interface.  They
  30.    also usually have a modem.  This allows them to communicate over the
  31.    telephone with any other similarly equipped computer.
  32.  
  33.    The telephone system is a pervasive network, but one of the
  34.    characteristics of the telephone system is the unpredictable quality
  35.    of the circuit.  The standard telephone circuit is designed for voice
  36.    communication and not data communication.  Voice communication
  37.    tolerates a much higher degree of 'noise' than does a data circuit,
  38.    so a voice circuit is tolerant of a much higher level of noise than
  39.    is a data circuit.  Thus it is not uncommon for a byte of data
  40.    transferred over a telephone circuit to have noise inserted.  For the
  41.    same reason it is also not uncommon to have spurious data bytes added
  42.    to the data stream.
  43.  
  44.    The need for a method of reliably transferring data over an RS-232
  45.    point-to-point link has become severe.  As the number of powerful
  46.    personal computers grows, the need for them to communicate with one
  47.    another grows as well.  The new markets and new services that these
  48.    computers will eventually allow their users to access will rely
  49.    heavily upon the telephone system.  Services like electronic mail,
  50.    electronic banking, ordering merchandise from home with a personal
  51.    computer, etc.  As the information revolution proceeds data itself
  52.    will become a commodity.  All require accuracy of the data sent or
  53.    received.
  54.  
  55.  
  56. Finn                                                            [Page 1]
  57.  
  58.  
  59.  
  60. RFC 916                                                     October 1984
  61. Reliable Asynchronous Transfer Protocol
  62.  
  63.  
  64. 1. Philosopy of Design
  65.  
  66.    Many tradeoffs were made in designing this protocol.  Decisions were
  67.    made by above all ensuring reliability and then by favoring
  68.    simplicity of implementation.  It is hoped that this protocol is
  69.    simple enough to be implemented not only by small computers but also
  70.    by stand alone devices incorporating microcomputers which accept
  71.    commands over RS-232 lines.  Sophisticated but unnecessary features
  72.    such as dynamic window management [TCP 81] were left out for
  73.    simplicity's sake.  Having several packets outstanding at a time was
  74.    eliminated for the same reason, and data queued to send when a
  75.    connection is closed remotely is discarded.  This eliminates two
  76.    states from the protocol implementation.
  77.  
  78.    The reader may ask why define this protocol at all, there are after
  79.    all already RS-232 transport protocols in use.  This is true but some
  80.    lack one or more features vitally important or are too complex.  See
  81.    Appendix II for a brief survey.
  82.  
  83.       - A protocol which can only transfer data in one direction is
  84.         unable to use a single RS-232 link for a full-duplex connection.
  85.         As such it cannot act as a bridge between most computer
  86.         networks.  Also it is not capable of supporting any applications
  87.         requiring the two-way exchange of data.  In particular it is not
  88.         a platform suitable for the creation of most higher level
  89.         applications.  Unidirectional flow of data is sufficient for a
  90.         weak implementation of file transfer but insufficient for remote
  91.         terminal service, transaction oriented processing, etc.
  92.  
  93.       - Some of the existing RS-232 transport protocols allow the use of
  94.         only fixed size packets or do not allow the receiver to place a
  95.         limit on the sender's packets.  Where that block size is too
  96.         large for the receiving end concentrator, that concentrator is
  97.         likely to immediately invoke flow control.  This results in many
  98.         dropped and damaged packets.  The receiver must be able to
  99.         inform the sender at connection initiation what is the maximum
  100.         packet size it is prepared to receive.
  101.  
  102.       - Some protocols have a number of features which may or may not be
  103.         implemented at each site.  Examples are, several checksumming
  104.         algorithms, differing data transmission restrictions, sometimes
  105.         8-bit data, sometimes restricted ASCII subsets, etc.  The
  106.         resulting requirement that all sites implement all the various
  107.         features is rarely met.
  108.  
  109.    Finally, the size of this document may be imposing.  The document
  110.    attempts to fully specify the behavior of the protocol.  A careful
  111.  
  112.  
  113. Finn                                                            [Page 2]
  114.  
  115.  
  116.  
  117. RFC 916                                                     October 1984
  118. Reliable Asynchronous Transfer Protocol
  119.  
  120.  
  121.    exposition of the protocol's behavior under all circumstances is
  122.    necessary to answer any questions an implementor might have, to make
  123.    it possible to verify the protocol, etc.  This size of this
  124.    specification should not be taken as an indication of the difficulty
  125.    of implementing it.
  126.  
  127.    1.1. The Host Environment
  128.  
  129.       This protocol is designed to operate on any point-to-point
  130.       communication link capable of transmitting and receiving data.  It
  131.       is not necessary that the link be asynchronous.  Because neither
  132.       end of a connection has control over when the other decides to
  133.       transmit, the link should be full duplex.  It is expected that in
  134.       the vast majority of circumstances an asynchronous full-duplex
  135.       RS-232 link will be used.
  136.  
  137.       In practice this protocol could reside anywhere from the RS-232
  138.       driver software on a microcomputer in a concentrator all the way
  139.       to the user software level.  Ideally it properly resides inside
  140.       the host operating system or concentrator.  It should be an option
  141.       associated with communication link which is selectable by the user
  142.       program.  If reliable data transmission were of great importance
  143.       then the software would choose the option.  Once the option were
  144.       chosen the initial connection handshaking would begin.
  145.  
  146.       There are many cases where this protocol will not reside in a host
  147.       operating system (initially this will always be so).  In addition
  148.       there are many pieces of stand-alone equipment which accept
  149.       commands over an RS-232 link.  A plotter is such an example.  To
  150.       have a several hour plot ruined by noise on an unreliable data
  151.       line is an all too often occurrence.  The sending and receiving
  152.       sides of the protocol should be as simple as possible allowing
  153.       applications software and stand alone devices to utilize the
  154.       protocol with little penalty of time or space.
  155.  
  156.    1.2. Relation to Other Protocols
  157.  
  158.       The "layering" concept has become the accepted way of designing
  159.       communications protocols.  Because this protocol will operate in a
  160.       point-to-point environment it comprises both the datagram and
  161.       reliable connection layers.  No multi-network capability is
  162.       implied.  Where a link using this protocol bridges differing
  163.       networks it is expected that other protocols like TCP will have
  164.       their packets fragmented and encapsulated inside the packets of
  165.       this protocol.
  166.  
  167.  
  168.  
  169.  
  170. Finn                                                            [Page 3]
  171.  
  172.  
  173.  
  174. RFC 916                                                     October 1984
  175. Reliable Asynchronous Transfer Protocol
  176.  
  177.  
  178. 2. Packet Specification
  179.  
  180.    RATP transmits data over a full-duplex communication link.  Data may
  181.    be transmitted in both directions over the link.  A stream of data is
  182.    communicated by being broken up into 8-bit pieces called octets.
  183.    These octets are serially accumulated to form a packet.  The packet
  184.    is the unit of data communicated over the link.  The protocol
  185.    virtually guarantees that the data transmitted at one end, if
  186.    received, arrives unaltered and intact at the other end.
  187.  
  188.    Within an octet all eight bits contain data.  All eight bits must be
  189.    preserved by the link interface and associated device driver.  In
  190.    many operating systems this is ensured by placing the connection into
  191.    RAW or BINARY data mode.  During normal operation packets are
  192.    transmitted and acknowledged one at a time over the link in each
  193.    direction.  Each packet is composed of a HEADER followed by a DATA
  194.    portion.  The DATA portion may be empty.
  195.  
  196.       NOTE: There are some older operating systems and devices which do
  197.       not permit 8-bit communication over an RS-232 link.  Most of these
  198.       allow restricted 7-bit communication.  RATP can automatically
  199.       detect this situation during connection initiation and utilizes a
  200.       special packing strategy when full 8-bit communication is not
  201.       possible.  This is entirely transparent to any client software.
  202.       See Appendix I for a discussion of this case.
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227. Finn                                                            [Page 4]
  228.  
  229.  
  230.  
  231. RFC 916                                                     October 1984
  232. Reliable Asynchronous Transfer Protocol
  233.  
  234.  
  235.    2.1. Header Format
  236.  
  237.       Byte No.
  238.  
  239.              +-------------------------------+
  240.              |                               |
  241.          1   |          Synch Leader         | Hex 01
  242.              |                               |
  243.              +-------------------------------+
  244.              | S | A | F | R | S | A | E | S |
  245.          2   | Y | C | I | S | N | N | O | O | Control
  246.              | N | K | N | T |   |   | R |   |
  247.              +-------------------------------+
  248.              |                               |
  249.          3   |      Data length (0-255)      |
  250.              |                               |
  251.              +-------------------------------+
  252.              |                               |
  253.          4   |        Header Checksum        |
  254.              |                               |
  255.              +-------------------------------+
  256.  
  257.                        Header Portion of a Packet
  258.  
  259.       2.1.1. Synch Leader
  260.  
  261.          RS-232 provides a self-clocking communications medium.  The
  262.          wires over which data flows are often placed in 'noisy'
  263.          environments where the noise can appear as added unwanted data.
  264.          For this reason the beginning of a packet is denoted by a one
  265.          octet SYNCH pattern.  This allows the receiver to discard noise
  266.          which appears on the connection prior to the reception of a
  267.          packet.  The SYNCH pattern is defined to be the one octet hex
  268.          01, the ASCII Start Of Header character <SOH>.
  269.  
  270.          The SYNCH pattern should ideally be unlikely to occur as the
  271.          result of noise.  Differing modems, etc. have differing
  272.          responses to noise so this is hard to achieve.  The pattern
  273.          chosen is thought to be a good compromise since many modems
  274.          manifest noise by setting the high order bits.  Situations will
  275.          occur in which receiver is scanning for the beginning of a
  276.          packet and a spurious SYNCH pattern is seen.  To detect
  277.          situations of this type a header checksum is provided (see
  278.          below).
  279.  
  280.  
  281.  
  282.  
  283.  
  284. Finn                                                            [Page 5]
  285.  
  286.  
  287.  
  288. RFC 916                                                     October 1984
  289. Reliable Asynchronous Transfer Protocol
  290.  
  291.  
  292.       2.1.2. Control Bits
  293.  
  294.          The first octet following the SYNCH pattern contains a 5-bit
  295.          field of control flags and two 1-bit sequence number fields.
  296.          The last bit is reserved and must be zero.
  297.  
  298.          2.1.2.1. SYN - Synchronize Flag
  299.  
  300.             Synchronize the connection.  No data may be sent in a packet
  301.             which has the SYN flag set.
  302.  
  303.          2.1.2.2. ACK - Acknowledge Flag
  304.  
  305.             Acknowledge number is significant.  Data may accompany a
  306.             packet which has this flag set as long as neither of SYN,
  307.             RST, nor FIN are also set.  Once a connection has been
  308.             established this is always set.
  309.  
  310.          2.1.2.3. RST - Reset Flag
  311.  
  312.             Reset the connection.  This is a method by which one end of
  313.             a connection can reset the other when an anomalous condition
  314.             is detected.  No data may be sent in a packet which has the
  315.             RST flag set.
  316.  
  317.          2.1.2.4. FIN - Finishing Flag
  318.  
  319.             This indicates that no more data will be sent to the other
  320.             end of the connection.  It also indicates that no more data
  321.             will be accepted.  No data may be sent in a packet which has
  322.             the FIN flag set.
  323.  
  324.          2.1.2.5. SN - Sequence Number
  325.  
  326.             The Sequence Number associated with this packet.
  327.  
  328.          2.1.2.6. AN - Acknowledge Number
  329.  
  330.             If the ACK control flag is set this is the next Sequence
  331.             Number the sender of the packet is expecting to receive.
  332.  
  333.          2.1.2.7. EOR - End of Record
  334.  
  335.             This bit is provided as an aid for higher level protocols
  336.             which may need to fragment their packets.  The Internet
  337.             protocol for example often uses packets as large as 576
  338.             octets.  A packet of such size would require fragmentation
  339.  
  340.  
  341. Finn                                                            [Page 6]
  342.  
  343.  
  344.  
  345. RFC 916                                                     October 1984
  346. Reliable Asynchronous Transfer Protocol
  347.  
  348.  
  349.             when transported using this protocol. The EOR bit if set
  350.             provides information to the higher level that a record is
  351.             terminated in this packet.  It is for information only and
  352.             is the responsibility of the higher level to set/clear it
  353.             when building packets to send.  The interface to the
  354.             protocol must provide a method of reading/setting/clearing
  355.             this bit.
  356.  
  357.          2.1.2.8. SO - Single Octet
  358.  
  359.             One application thought to be of special importance is
  360.             single character transmission --- a user communicates from
  361.             the keyboard of a personal computer to another computer over
  362.             an unreliable link.  Since rapid interactive response is
  363.             desirable it is expected that many of the characters typed
  364.             will be transmitted individually.  To minimize the overhead
  365.             of this special case the SO control flag is provided.
  366.  
  367.             The SO flag has no meaning if either the SYN, RST, or FIN
  368.             flags are set.  Assume none of those flags are set, then if
  369.             the SO flag is set it indicates that a single octet of data
  370.             is contained in this packet. Since the amount of data is
  371.             known to be one octet the LENGTH field is superfluous and
  372.             itself contains the data octet.  The data portion of the
  373.             packet is not transmitted.
  374.  
  375.             The SO flag removes the need to transmit the data portion of
  376.             the packet in this special case.  Without the SO flag seven
  377.             octets would be required of the packet, with it only four
  378.             are needed and so transmission efficiency is improved by 40
  379.             percent.  The header checksum protects the single octet of
  380.             data.
  381.  
  382.       2.1.3. Length
  383.  
  384.          The second octet following the SYNCH pattern holds length
  385.          information.  If the SYN bit is present this contains the
  386.          maximum number of data octets the receiver is allowed to
  387.          transmit in any single packet to the sender.  This quantity is
  388.          called the MDL.  A sender may indicate his unwillingness to
  389.          accept any data octets by specifying an MDL of zero.  In this
  390.          case presumably all the data would be moving from the sender to
  391.          the receiver.  Obviously if data is to be transmitted both
  392.          sides of a connection cannot have an MDL of zero.
  393.  
  394.          If neither the SYN, RST, nor FIN flags are set this is an 8-bit
  395.          field called LENGTH.  In this case if the SO flag bit is set
  396.  
  397.  
  398. Finn                                                            [Page 7]
  399.  
  400.  
  401.  
  402. RFC 916                                                     October 1984
  403. Reliable Asynchronous Transfer Protocol
  404.  
  405.  
  406.          then LENGTH contains a single octet of data.  Otherwise it
  407.          contains the count of data octets in this packet.  From zero
  408.          (0) to MDL octets of data may appear in a single packet.  MDL
  409.          is limited to a maximum of 255.
  410.  
  411.       2.1.4. Header Checksum
  412.  
  413.          The header checksum algorithm is the 8-bit equivalent of the
  414.          16-bit data checksum detailed below.  It is built and processed
  415.          in an similar manner but is eight bits wide instead of sixteen.
  416.          When sending the header checksum octet is initially cleared.
  417.          An 8-bit sum of the control, length, and header checksum octets
  418.          is formed employing end-around carry.  That sum is then
  419.          complemented and stored in the header checksum octet.  Upon
  420.          receipt the 8-bit end-around carry sum is formed of the same
  421.          three octets.  If the sum is octal 377 the header is presumed
  422.          to be valid.  In all other cases the header is assumed to be
  423.          invalid.
  424.  
  425.          The reasons for providing this separate protection to the
  426.          header are discussed in the chapter dealing with error
  427.          handling.  The header checksum covers the control and data
  428.          length octets.  It does not include the SYNCH pattern.
  429.  
  430.    2.2. Data Format
  431.  
  432.       The data portion of a packet immediately follows the header if the
  433.       SO flag is not set and LENGTH > 0.  It consists of LENGTH data
  434.       octets  immediately followed by two data checksum octets.  If
  435.       present the data portion contains LENGTH+2 octets.
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455. Finn                                                            [Page 8]
  456.  
  457.  
  458.  
  459. RFC 916                                                     October 1984
  460. Reliable Asynchronous Transfer Protocol
  461.  
  462.  
  463.       Data Byte No.
  464.  
  465.                   +-------------------------------+
  466.          1        |                               | High order \
  467.                   +--                           --+             > Word
  468.          2        |                               | Low order  /
  469.                   +--                           --+
  470.          .        |            Data               | High order \
  471.                   +--                           --+             > Word
  472.          .        |                               | Low order  /
  473.                   +--                           --+
  474.          LENGTH   |                               | High order \
  475.                   +-------------------------------+             > Word
  476.                   |   Imaginary padding octet 0   | Low order  /
  477.                   +-------------------------------+
  478.          LENGTH+1 |                               | High order \
  479.                   +--       Data Checksum       --+             > Word
  480.          LENGTH+2 |                               | Low order  /
  481.                   +-------------------------------+
  482.  
  483.                         Data Portion of a Packet
  484.  
  485.       2.2.1. Data Checksum
  486.  
  487.          The last two octets of the data portion of a packet are a data
  488.          checksum.  A 16-bit checksum is used by this protocol to detect
  489.          incorrectly transmitted data.  This has shown itself to be a
  490.          reliable method for detecting most categories of bit drop out
  491.          and bit insertion.  While it does not guarantee the detection
  492.          of all such errors the probability of such an error going
  493.          undetected is on the order of 2**(-16).
  494.  
  495.          The checksum octets follow the data to enable the sender of a
  496.          packet to compute the checksum while transmitting a packet and
  497.          the receiver to compute the checksum while receiving the
  498.          packet.  Thus neither must store the packet and then process
  499.          the data for checksumming in a separate pass.
  500.  
  501.          Order of Transmission
  502.  
  503.             The order in which the 8-bit octets are assembled into
  504.             16-bit words, which is the low order octet and which is the
  505.             high, must be rigidly specified for the purpose of computing
  506.             16-bit checksums.  We specify the big endian ordering in the
  507.             diagram above [Cohen 81].
  508.  
  509.  
  510.  
  511.  
  512. Finn                                                            [Page 9]
  513.  
  514.  
  515.  
  516. RFC 916                                                     October 1984
  517. Reliable Asynchronous Transfer Protocol
  518.  
  519.  
  520.          Checksum Algorithm
  521.  
  522.             The checksum algorithm chosen is similar to that used by
  523.             IP/TCP protocols [IP 81] [TCP 81].  This algorithm has shown
  524.             itself to be both reliable and relatively easy to compute.
  525.             The interested reader may refer to [TCP Checksum 78] for a
  526.             more thorough discussion of its properties.
  527.  
  528.          The checksum algorithm is:
  529.  
  530.             SENDER
  531.  
  532.                The unsigned sum of the 16-bit words of the data portion
  533.                of the packet is formed.  Any overflow is added into the
  534.                lowest order bit.  This sum does not include the header
  535.                portion of the packet.  For the purpose of building a
  536.                packet for transmission the two octet checksum field is
  537.                zero.  The sum formed is then bit complemented and
  538.                inserted into the checksum field before transmission.
  539.  
  540.                If the total number of data octets is odd then the last
  541.                octet is padded to the right (low order) with zeros to
  542.                form a 16-bit word for checksum purposes.  This pad octet
  543.                is not transmitted as part of the packet.
  544.  
  545.             RECEIVER
  546.  
  547.                The sum is computed as above but including the values
  548.                received in the checksum field.  If the 16-bit sum is
  549.                octal 177777 then the data is presumed to be valid.  In
  550.                all other cases the data is presumed to be invalid.
  551.  
  552.          This unsigned 16-bit sum adds 16-bit quantities with any
  553.          overflow bit added into the lowest order bit of the sum.  This
  554.          is called 'end around carry'.  End around carry addition
  555.          provides several properties: 1) It provides full commutivity of
  556.          addition (summing in any order is equivalent), and 2) If you
  557.          apply a given rotation to each quantity before addition and
  558.          when the final total is formed apply the inverse rotation, then
  559.          the result will be equivalent to any other rotation chosen.
  560.          The latter property gives little endian machines like a PDP-11
  561.          the go ahead to pick up 16-bit quantities and add them in byte
  562.          swapped order.
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569. Finn                                                           [Page 10]
  570.  
  571.  
  572.  
  573. RFC 916                                                     October 1984
  574. Reliable Asynchronous Transfer Protocol
  575.  
  576.  
  577.             The PDP-11 code to calculate the checksum is:
  578.  
  579.                      CLR R0         ; R0 will get the checksum
  580.                                     ; R2 contains LENGTH count
  581.                LOOP: ADD (R1)+,R0   ; Add the next 16-bit byte
  582.                      ADC R0         ; Make any carry be end around
  583.                      SOB R2,LOOP    ; Loop over entire packet
  584.                      COM R0         ; Bit complement result
  585.  
  586.    2.3. Sequence Numbers
  587.  
  588.       Sequence numbers work with acknowledge numbers to inform the
  589.       sender that his last data packet was received, and to inform the
  590.       receiver of the sequence number of the next data packet it expects
  591.       to see.  When the ACK flag is set in a packet the AN field
  592.       contains the sequence number of the next data packet it expects
  593.       from the sender.  The sender looks at the AN field and by
  594.       implication knows that the packet he just sent should have had a
  595.       sequence number of:
  596.  
  597.          <AN received-1 modulo 2>
  598.  
  599.       If it did have that number that packet is considered to have been
  600.       acknowledged.
  601.  
  602.       Similarly, the receiver expects the next data packet it sees to
  603.       have an SN field value equal to the AN field of the last
  604.       acknowledge message it sent.  If this is not the case then the
  605.       receiver assumes that it is receiving a duplicate of a data packet
  606.       it earlier acknowledged.  This implies that the packet containing
  607.       the acknowledgment did not arrive and therefor the packet that
  608.       contained the acknowledgment should be retransmitted.  The
  609.       duplicate data packet is discarded.
  610.  
  611.       The only packets which require acknowledgment are packets
  612.       containing status flags (SYN, RST, FIN, or SO) or data.  A packet
  613.       which contains only an acknowledgment, i.e. <AN=n><CTL=ACK>, does
  614.       not require a response (it contains no status flags or data).
  615.  
  616.       Both the AN and SN fields are a single bit wide.  Since at most
  617.       one packet is in the process of being sent/acknowledged in a
  618.       particular direction at any one time a single bit is sufficient to
  619.       provide a method of duplicate packet detection and removal of a
  620.       packet from the retransmission queue.  The arithmetic to advance
  621.       these numbers is modulo 2.  Thus when a data packet has been
  622.       acknowledged the sender's next sequence number will be the current
  623.       one, plus one modulo 2:
  624.  
  625.  
  626. Finn                                                           [Page 11]
  627.  
  628.  
  629.  
  630. RFC 916                                                     October 1984
  631. Reliable Asynchronous Transfer Protocol
  632.  
  633.  
  634.          <SN = SN + 1 modulo 2>
  635.  
  636.       The individual acknowledgment of each packet containing data can
  637.       mislead one into thinking that side A of a connection cannot send
  638.       data to side B until it receives a packet from B. That only then
  639.       can it acknowledge B's packet and place in the acknowledging
  640.       packet some data of its own.  This is not the case.
  641.  
  642.       As long as its last packet sent requiring a response has been
  643.       acknowledged each side of a connection is free to send a data
  644.       packet whenever it wishes.  Naturally, if one side is sending a
  645.       data packet and it also must acknowledge receipt of a data packet
  646.       from the other side, it is most efficient to combine both
  647.       functions in a single packet.
  648.  
  649.    2.4. Maximum Packet Size
  650.  
  651.       The maximum packet size is:
  652.  
  653.          SYNCH + HEADER + Data Checksum + 255 = 261 octets
  654.  
  655.       There is therefor no need to allocate more than that amount of
  656.       storage for any received packets.
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683. Finn                                                           [Page 12]
  684.  
  685.  
  686.  
  687. RFC 916                                                     October 1984
  688. Reliable Asynchronous Transfer Protocol
  689.  
  690.  
  691. 3. The Opening and Closing of a Connection
  692.  
  693.    3.1. Opening a Connection
  694.  
  695.       A "three-way handshake" is the procedure used to establish a
  696.       connection.  It is normally initiated by one end of the connection
  697.       and responded to by the other.  It will still work if both sides
  698.       simultaneously initiate the procedure.  Experience has shown that
  699.       this strategy of opening a connection reduces the probability of
  700.       false connections to an acceptably low level.
  701.  
  702.       The simplest form of the three-way handshake is illustrated in the
  703.       diagram below.  The time order is line by line from top to bottom
  704.       with certain lines numbered for reference.  User events are placed
  705.       in brackets as in [OPEN].  An arrow (-->) represents the direction
  706.       of flow of a packet and an ellipsis (...) indicates a packet in
  707.       transit.  Side A and side B are the two ends of the connection.
  708.       An "XXX" indicates a packet which is lost or rejected.  The
  709.       contents of the packet are shown on the center of each line.  The
  710.       state of both connections is that caused by the departure or
  711.       arrival of the packet represented on the line.  The contents of
  712.       the data portion of a packet are left out for clarity.
  713.  
  714.       Side A                                             Side B
  715.  
  716.       1. CLOSED                                          LISTEN
  717.  
  718.       2. [OPEN request]
  719.           SYN-SENT ->   <SN=0><CTL=SYN><MDL=n>     ...
  720.  
  721.       3.                                           -->   SYN-RECEIVED
  722.               ... <SN=0><AN=1><CTL=SYN,ACK><MDL=m> <--
  723.  
  724.       4. ESTABLISHED <--
  725.               -->    <SN=1><AN=1><CTL=ACK><DATA>   ...
  726.  
  727.       5.                                           -->   ESTABLISHED
  728.  
  729.       In line 2 above the user at side A has requested that a connection
  730.       be opened.  Side A then attempts to open a connection by sending a
  731.       SYN packet to side B which is in the LISTEN state.  It specifies
  732.       its initial sequence number, here zero.  It places in the LENGTH
  733.       field of the header the largest number of data octets it can
  734.       consume in any one packet (MDL).  The MDL is normally positive.
  735.       The action of sending this packet places A in the SYN-SENT state.
  736.  
  737.       In line 3 side B has just received the SYN packet from A. This
  738.  
  739.  
  740. Finn                                                           [Page 13]
  741.  
  742.  
  743.  
  744. RFC 916                                                     October 1984
  745. Reliable Asynchronous Transfer Protocol
  746.  
  747.  
  748.       places B in the SYN-RECEIVED state.  B now sends a SYN packet to A
  749.       which acknowledges the SYN it just received from A. Note that the
  750.       AN field indicates B is now expecting to hear SN=1, thus
  751.       acknowledging the SYN packet from A which used SN=0.  B also
  752.       specifies in the LENGTH field the largest number of data octets it
  753.       is prepared to consume.
  754.  
  755.       Side A receives the SYN packet from B which acknowledges A's
  756.       original SYN packet in line 4.  This places A in the ESTABLISHED
  757.       state.  Side A can now be confident that B expects to receive more
  758.       packets from A.
  759.  
  760.       A is now free to send B the first DATA packet.  In line 5 upon
  761.       receipt of this packet side B is placed into the ESTABLISHED
  762.       state.  DATA cannot be sent until the sender is in the ESTABLISHED
  763.       state.  This is because the LENGTH field is used to specify the
  764.       MDL when opening the connection.
  765.  
  766.    3.2. Recovering from a Simultaneous Active OPEN
  767.  
  768.       It is of course possible that both ends of a connection may choose
  769.       to  perform an active OPEN simultaneously.  In this case neither
  770.       end of the connection is in the LISTEN state, both send SYN
  771.       packets.  A reliable bidirectional protocol must recover from this
  772.       situation.  It should recover in such a manner that the connection
  773.       is successfully initiated.
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797. Finn                                                           [Page 14]
  798.  
  799.  
  800.  
  801. RFC 916                                                     October 1984
  802. Reliable Asynchronous Transfer Protocol
  803.  
  804.  
  805.       Side A                                             Side B
  806.  
  807.       1. CLOSED                                          CLOSED
  808.  
  809.       2. [OPEN request]
  810.          SYN-SENT -->  <SN=0><CTL=SYN><MDL=n>       ...
  811.  
  812.       3.     ...                                         [OPEN request]
  813.                        <SN=0><CTL=SYN><MDL=m>       <--  SYN-SENT
  814.  
  815.       4.                                            -->  SYN-RECEIVED
  816.              ...  <SN=0><AN=1><CTL=SYN,ACK><MDL=m>  <--
  817.  
  818.       5. (packet finally arrives)
  819.          SYN-RECEIVED  <--  <SN=0><CTL=SYN><MDL=m>
  820.  
  821.              -->  <SN=0><AN=1><CTL=SYN,ACK><MDL=n>  -->  ESTABLISHED
  822.               ...       <SN=1><AN=1><CTL=ACK>       <--
  823.  
  824.       6. (packet finally arrives)
  825.          ESTABLISHED <-- <SN=0><AN=1><CTL=SYN,ACK><MDL=m>
  826.                      -->   <SN=1><AN=1><CTL=ACK>    ...
  827.  
  828.       During simultaneous connection both  sides  of  the  connection
  829.       cycle  from  the CLOSED state through SYN-SENT to SYN-RECEIVED,
  830.       and finally to ESTABLISHED.
  831.  
  832.    3.3. Detecting a Half-Open Connection
  833.  
  834.       Any computer may crash after a connection has been established.
  835.       After recovering from the crash it may attempt to open a new
  836.       connection.  The other end must be able to detect this condition
  837.       and treat it as an error.
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854. Finn                                                           [Page 15]
  855.  
  856.  
  857.  
  858. RFC 916                                                     October 1984
  859. Reliable Asynchronous Transfer Protocol
  860.  
  861.  
  862.       Side A                                             Side
  863.  
  864.       1. ESTABLISHED                                     ESTABLISHED
  865.  
  866.                 -->   <SN=0><AN=1><CTL=ACK><DATA>  ...
  867.                                                    -->
  868.       (crashes)
  869.  
  870.       2.        XXX   <SN=1><AN=1><CTL=ACK><DATA>  <--
  871.  
  872.       3. (attempts to open new connection )
  873.                 -->    <SN=0><CTL=SYN><MDL=m>      -->
  874.                 ...  <SN=0><AN=1><CTL=RST,ACK>     <--   (abort)
  875.                                                          CLOSED
  876.  
  877.       4.        <--
  878.       (connection refused)
  879.          CLOSED
  880.  
  881.    3.4. Closing a Connection
  882.  
  883.       Either side may choose to close an established connection.  This
  884.       is accomplished by sending a packet with the FIN  control bit set.
  885.       No  data may appear in a FIN packet.  The other end of the
  886.       connection responds by shutting down its end of the connection and
  887.       sending a FIN, ACK in response.
  888.  
  889.       Side A                                             Side B
  890.  
  891.       1. ESTABLISHED                                     ESTABLISHED
  892.  
  893.       2. [CLOSE request from user]
  894.          FIN-WAIT  -->     <SN=0><AN=1><CTL=FIN>    ...
  895.  
  896.       3.                                            -->  LAST-ACK
  897.                    ...   <SN=1><AN=1><CTL=FIN,ACK>  <--
  898.  
  899.       4. TIME-WAIT <--
  900.                    -->     <SN=1><AN=0><CTL=ACK>    ...
  901.  
  902.       5.                                            -->  CLOSED
  903.  
  904.       6. (after 2*SRTT time passes)
  905.          CLOSED
  906.  
  907.       In line 2 the user on side A of the fully opened connection has
  908.       decided to close it down by issuing a CLOSE call.  No more data
  909.  
  910.  
  911. Finn                                                           [Page 16]
  912.  
  913.  
  914.  
  915. RFC 916                                                     October 1984
  916. Reliable Asynchronous Transfer Protocol
  917.  
  918.  
  919.       will be accepted for sending.  If data remains unsent a message
  920.       "Warning: Unsent data remains." is communicated to the user.  No
  921.       more data will be received.  A packet containing a FIN but no data
  922.       is constructed and sent.  Side A goes into the FIN-WAIT state.
  923.  
  924.       Side B sees the FIN sent and immediately builds a FIN, ACK packet
  925.       in response.  It then goes into the LAST-ACK state.  The FIN, ACK
  926.       packet is received by side A and an answering ACK is immediately
  927.       sent.  Side A then goes to the TIME-WAIT state.  In line 5 side B
  928.       receives the final acknowledgment of its FIN, ACK packet and goes
  929.       to the CLOSED state.  In line 6 after waiting to be sure its last
  930.       acknowledgment was received side A goes to the CLOSED state (SRTT
  931.       is the Smoothed Round Trip Time and is defined in section 6.3.1).
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954.  
  955.  
  956.  
  957.  
  958.  
  959.  
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968. Finn                                                           [Page 17]
  969.  
  970.  
  971.  
  972. RFC 916                                                     October 1984
  973. Reliable Asynchronous Transfer Protocol
  974.  
  975.  
  976. 4. Packet Reception
  977.  
  978.    The act of receiving a packet is relatively straightforward.  There
  979.    are a few points which deserve some discussion.  This chapter will
  980.    discuss packet reception stage by stage in time order.
  981.  
  982.    Synch Detection
  983.  
  984.       The first stage in the reception of a packet is the discovery of a
  985.       SYNCH pattern.  Octets are read continuously and discarded until
  986.       the SYNCH pattern is seen.  Once SYNCH has been observed proceed
  987.       to the Header Reception stage.
  988.  
  989.    Header Reception
  990.  
  991.       The remainder of the header is three octets in length.  No further
  992.       processing can continue until the complete header has been read.
  993.       Once read the header checksum test is performed.  If this test
  994.       fails it is assumed that the current SYNCH pattern was the result
  995.       of a data error.  Since the correct SYNCH may appear immediately
  996.       after the current one, go back to the Synch Detection stage but
  997.       treat the three octets of the header following the bad SYNCH as
  998.       new input.
  999.  
  1000.       If the header checksum test succeeds then proceed to the Data
  1001.       Reception stage.
  1002.  
  1003.    Data Reception
  1004.  
  1005.       A determination of the remaining length of the packet is made.  If
  1006.       either of the SYN, RST, SO, or FIN flags are set then legally the
  1007.       entire packet has already been read and it is considered to have
  1008.       'arrived'.  No data portion of a packet is present when one of
  1009.       those flags is set.  Otherwise the LENGTH field specifies the
  1010.       remaining amount of data to read.  In this case if the LENGTH
  1011.       field is zero then the packet contains no data portion and it is
  1012.       considered to have arrived.
  1013.  
  1014.       We now assume that a data portion is present and LENGTH was
  1015.       non-zero.  Counting the data checksum LENGTH+2 octets must now be
  1016.       read.  Once read the data checksum test is performed.  If this
  1017.       test fails the entire packet is discarded, return to the Synch
  1018.       Detection stage.  If the test succeeds then the packet is
  1019.       considered to have arrived.
  1020.  
  1021.  
  1022.  
  1023.  
  1024.  
  1025. Finn                                                           [Page 18]
  1026.  
  1027.  
  1028.  
  1029. RFC 916                                                     October 1984
  1030. Reliable Asynchronous Transfer Protocol
  1031.  
  1032.  
  1033.    Once arrived the packet is released to the upper level protocol
  1034.    software.  In a multiprocess implementation packet reception would
  1035.    now begin again at the Synch Detection stage.
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066.  
  1067.  
  1068.  
  1069.  
  1070.  
  1071.  
  1072.  
  1073.  
  1074.  
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082. Finn                                                           [Page 19]
  1083.  
  1084.  
  1085.  
  1086. RFC 916                                                     October 1984
  1087. Reliable Asynchronous Transfer Protocol
  1088.  
  1089.  
  1090. 5. Functional Specification
  1091.  
  1092.    A convenient model for the discussion and implementation of protocols
  1093.    is that of a state machine.  A connection can be thought of as
  1094.    passing through a variety of states, with possible error conditions,
  1095.    from its inception until it is closed.  In such a model each state
  1096.    represents a known point in the history of a connection.  The
  1097.    connection passes from state to state in response to events.  These
  1098.    events are caused by user calls to the protocol interface (a request
  1099.    to open or close a connection, data to send, etc.), incoming packets,
  1100.    and timeouts.
  1101.  
  1102.    Information about a connection must be maintained at both ends of
  1103.    that connection.  Following the terminology of [TCP 81] the
  1104.    information necessary to the successful operation of a connection is
  1105.    called the Transmission Control Block or TCB.  The user requests to
  1106.    the protocol interface are OPEN, SEND, RECEIVE, ABORT, STATUS, and
  1107.    CLOSE.
  1108.  
  1109.    This chapter is broken up into three parts.  First a brief
  1110.    description of each protocol state will be presented.  Following this
  1111.    is a slightly more detailed look at the allowed transitions which
  1112.    occur between states.  Finally a detailed discussion of the behavior
  1113.    of each state is given.
  1114.  
  1115.    5.1. Protocol States
  1116.  
  1117.       The states used to describe this protocol are:
  1118.  
  1119.          LISTEN
  1120.  
  1121.             This state represents waiting for a connection from the
  1122.             other end of the link.
  1123.  
  1124.          SYN-SENT
  1125.  
  1126.             This represents waiting for a matching connection request
  1127.             after having sent a connection request.
  1128.  
  1129.          SYN-RECEIVED
  1130.  
  1131.             This represents waiting for a confirming connection request
  1132.             acknowledgment after having both received and sent a
  1133.             connection request.
  1134.  
  1135.  
  1136.  
  1137.  
  1138.  
  1139. Finn                                                           [Page 20]
  1140.  
  1141.  
  1142.  
  1143. RFC 916                                                     October 1984
  1144. Reliable Asynchronous Transfer Protocol
  1145.  
  1146.  
  1147.          ESTABLISHED
  1148.  
  1149.             This state represents a connection fully opened at both
  1150.             ends.  This is the normal state for data transfer.
  1151.  
  1152.          FIN-WAIT
  1153.  
  1154.             In this state one is waiting for a connection termination
  1155.             request from the other end of the connection and an
  1156.             acknowledgment of a termination request previously sent.
  1157.  
  1158.          LAST-ACK
  1159.  
  1160.             This end of the connection has seen and acknowledged a
  1161.             termination request from the other end.  This end has
  1162.             responded with a termination request of its own and is now
  1163.             expecting an acknowledgment of that request.
  1164.  
  1165.          CLOSING
  1166.  
  1167.             This represents waiting for an acknowledgment of a
  1168.             connection termination request.
  1169.  
  1170.          TIME-WAIT
  1171.  
  1172.             This represents waiting for enough time to pass to be sure
  1173.             that the other end of the connection received the
  1174.             acknowledgment of its termination request.
  1175.  
  1176.          CLOSED
  1177.  
  1178.             A fictional state which represents a completely terminated
  1179.             connection.  If either end of a connection is in this state
  1180.             it will neither send nor receive data or control packets.
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.  
  1193.  
  1194.  
  1195.  
  1196. Finn                                                           [Page 21]
  1197.  
  1198.  
  1199.  
  1200. RFC 916                                                     October 1984
  1201. Reliable Asynchronous Transfer Protocol
  1202.  
  1203.  
  1204.    5.2. State Transitions
  1205.  
  1206.       This section describes events which cause the protocol to depart
  1207.       from its current state.  A brief mention of each state is
  1208.       accompanied by a list of departure events and to which state the
  1209.       protocol goes as a result of those events.  Departures due to the
  1210.       presence of a RST flag are not shown.
  1211.  
  1212.       5.2.1. LISTEN
  1213.  
  1214.          This is a request to listen for any connection from the other
  1215.          end of the link.  In this state, no packets are sent.  The
  1216.          connection may be thought of as half-open.  A STATUS request
  1217.          will return to the caller this information.
  1218.  
  1219.          Arrived at from the CLOSED state in response to a passive OPEN.
  1220.          In a passive OPEN no packets are sent, the interface is waiting
  1221.          for the initiation of a connection from the other end of the
  1222.          link.  Also this state can be reached in certain cases in
  1223.          response to an RST connection reset request.
  1224.  
  1225.          Departures
  1226.  
  1227.             - A CLOSE request is made by the user.  Delete the half-open
  1228.               TCB and go to the CLOSED state.
  1229.  
  1230.             - A packet arrives with the SYN flag set.  Retrieve the
  1231.               sender's MDL he placed into the LENGTH field.  Set AN to
  1232.               be received SN+1 modulo 2.  Build a response packet with
  1233.               SYN, ACK set.  Choose your MDL and place it into the
  1234.               LENGTH octet.  Choose your initial SN, place in AN.  Send
  1235.               this packet and go to the SYN-RECEIVED state.
  1236.  
  1237.       5.2.2. SYN-SENT
  1238.  
  1239.          Arrived at from the CLOSED state in response to a user's active
  1240.          OPEN request.
  1241.  
  1242.          Departures
  1243.  
  1244.             - A CLOSE request is made by the user.  Delete the TCB and
  1245.               go to the CLOSED state.
  1246.  
  1247.             - A packet arrives with the SYN flag set.  Retrieve the
  1248.               sender's MDL he placed into the LENGTH field.  Set AN to
  1249.  
  1250.  
  1251.  
  1252.  
  1253. Finn                                                           [Page 22]
  1254.  
  1255.  
  1256.  
  1257. RFC 916                                                     October 1984
  1258. Reliable Asynchronous Transfer Protocol
  1259.  
  1260.  
  1261.               be received SN+1 modulo 2.  Build a response packet with
  1262.               ACK set, place in AN.  Send this packet and go to the
  1263.               SYN-RECEIVED state.
  1264.  
  1265.             - A packet arrives with the SYN, ACK flags set.  Retrieve
  1266.               the sender's MDL he placed into the LENGTH field.  Set AN
  1267.               to be received SN+1 modulo 2.  Build a response packet
  1268.               with ACK set.  Set SN to be SN+1 modulo 2, place SN and AN
  1269.               into the header.  Remembering the other end's MDL, build
  1270.               data portion of packet.  Send this packet and go to the
  1271.               ESTABLISHED state.
  1272.  
  1273.       5.2.3. SYN-RECEIVED
  1274.  
  1275.          Arrived at from the LISTEN and SYN-SENT states in response to
  1276.          an arriving SYN packet.
  1277.  
  1278.          Departures
  1279.  
  1280.             - A CLOSE request is made by the user.  Create a packet with
  1281.               FIN set.  Send it and go to the FIN-WAIT state.
  1282.  
  1283.             - A packet arrives with the ACK flag set.  This packet
  1284.               acknowledges a previous SYN packet.  Go to the ESTABLISHED
  1285.               state.  The TCB should now note the connection is fully
  1286.               opened.
  1287.  
  1288.             - A packet arrives with the FIN flag set.  The other end has
  1289.               decided to close the connection.  Create a packet with
  1290.               FIN, ACK set.  Send it and go to the LAST-ACK state.
  1291.  
  1292.       5.2.4. ESTABLISHED
  1293.  
  1294.          This state is the normal state for a connection.  Data packets
  1295.          may be exchanged in both directions (MDL allowing).  It is
  1296.          arrived at from the SYN-RECEIVED and SYN-SENT states in
  1297.          response to the completion of connection initiation.
  1298.  
  1299.          Departures
  1300.  
  1301.             - In response to a CLOSE request from the user.  Set AN to
  1302.               be most recently received SN+1 modulo 2.  Build a packet
  1303.               with FIN set.  Set SN to be SN+1 modulo 2, place SN and AN
  1304.               into the header and send the packet.  Go to the FIN-WAIT
  1305.               state.
  1306.  
  1307.             - A packet containing a FIN is received.  Set AN to be
  1308.  
  1309.  
  1310. Finn                                                           [Page 23]
  1311.  
  1312.  
  1313.  
  1314. RFC 916                                                     October 1984
  1315. Reliable Asynchronous Transfer Protocol
  1316.  
  1317.  
  1318.               received SN+1 modulo 2.  Build a response packet with both
  1319.               FIN and ACK set.  Set SN to be SN+1 modulo 2, place SN and
  1320.               AN into the header.  No data portion is built.  Send this
  1321.               packet and go to the LAST-ACK state.
  1322.  
  1323.       5.2.5. FIN-WAIT
  1324.  
  1325.          Arrived at from either the SYN-RECEIVED state or from the
  1326.          ESTABLISHED state.  In both cases the user had requested a
  1327.          CLOSE of the connection and a packet with a FIN was sent.
  1328.  
  1329.          Departures
  1330.  
  1331.             - A FIN, ACK packet is received which acknowledges the FIN
  1332.               just sent.  Go to the TIME-WAIT state.
  1333.  
  1334.             - A FIN packet is received which indicates the other end of
  1335.               the connection has simultaneously decided to close.  Set
  1336.               AN=received SN+1 modulo 2, and SN=SN+1 modulo 2.  Send a
  1337.               response packet with the ACK set.  Go to the CLOSING
  1338.               state.
  1339.  
  1340.       5.2.6. LAST-ACK
  1341.  
  1342.          Arrived at from the ESTABLISHED and SYN-RECEIVED states.
  1343.  
  1344.          Departures
  1345.  
  1346.             - An ACK is received for the last packet sent which was a
  1347.               FIN.  Delete the TCB and go to the CLOSED state.
  1348.  
  1349.       5.2.7. CLOSING
  1350.  
  1351.          Arrived at from the FIN-WAIT state.
  1352.  
  1353.          Departures
  1354.  
  1355.             - An ACK is received for the last packet sent which was a
  1356.               FIN.  Go to the TIME-WAIT state.
  1357.  
  1358.       5.2.8. TIME-WAIT
  1359.  
  1360.          Arrived at from the FIN-WAIT and CLOSING states.
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367. Finn                                                           [Page 24]
  1368.  
  1369.  
  1370.  
  1371. RFC 916                                                     October 1984
  1372. Reliable Asynchronous Transfer Protocol
  1373.  
  1374.  
  1375.          Departures
  1376.  
  1377.             - This states waits until 2*SRTT time has passed.  It then
  1378.               deletes the TCB associated with the connection and goes to
  1379.               the CLOSED state.
  1380.  
  1381.       5.2.9. CLOSED
  1382.  
  1383.          This state can be arrived at for a number of reasons: 1) while
  1384.          in the LISTEN state the user requests a CLOSE, 2) while in the
  1385.          SYN-SENT state the user requests a CLOSE, 3) while in the
  1386.          TIME-WAIT state the 2*SRTT time period has elapsed, and 4)
  1387.          while in the LAST-ACK state an arriving packet has an ACK of
  1388.          the previously sent FIN packet.
  1389.  
  1390.          In this state no data is read or sent over the link.  To leave
  1391.          this state requires an outside request to open a new
  1392.          connection.
  1393.  
  1394.          Departures
  1395.  
  1396.             - User requests an active OPEN.  Create a packet with SYN
  1397.               set.  Choose your MDL and place it into the LENGTH octet.
  1398.               Choose your initial SN.  AN is immaterial.  Send this
  1399.               packet and go to the SYN-SENT state.  The TCB for this
  1400.               connection is created.  The connection may be thought of
  1401.               as half-open.  A STATUS request will return to the caller
  1402.               this information.
  1403.  
  1404.             - User requests a passive OPEN.  The TCB for this connection
  1405.               is created.  The connection may be thought of as
  1406.               half-open.  A STATUS request will return to the caller
  1407.               this information.  Go to the LISTEN state.
  1408.  
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421.  
  1422.  
  1423.  
  1424. Finn                                                           [Page 25]
  1425.  
  1426.  
  1427.  
  1428. RFC 916                                                     October 1984
  1429. Reliable Asynchronous Transfer Protocol
  1430.  
  1431.  
  1432.    5.3. State Behavior
  1433.  
  1434.       This section discusses in detail the behavior of each state in
  1435.       response to the arrival of a packet.  In what follows a packet is
  1436.       not considered to have arrived until it has passed a number of
  1437.       tests (see the chapter entitled: Packet Reception).
  1438.  
  1439.       The method chosen to describe state behavior is tabular.  Each
  1440.       state is listed opposite a sequence of named procedures to execute
  1441.       whenever a packet has arrived.
  1442.  
  1443.       STATE                BEHAVIOR
  1444.       =============+========================
  1445.       LISTEN       |  A
  1446.       -------------+------------------------
  1447.       SYN-SENT     |  B
  1448.       -------------+------------------------
  1449.       SYN-RECEIVED |  C1  D1  E  F1  H1
  1450.       -------------+------------------------
  1451.       ESTABLISHED  |  C2  D2  E  F2  H2  I1
  1452.       -------------+------------------------
  1453.       FIN-WAIT     |  C2  D2  E  F3  H3
  1454.       -------------+------------------------
  1455.       LAST-ACK     |  C2  D3  E  F3  H4
  1456.       -------------+------------------------
  1457.       CLOSING      |  C2  D3  E  F3  H5
  1458.       -------------+------------------------
  1459.       TIME-WAIT    |  D3  E  F3 H6
  1460.       -------------+------------------------
  1461.       CLOSED       |  G
  1462.       -------------+------------------------
  1463.  
  1464.       For example, in the ESTABLISHED state the arrival of a packet
  1465.       causes procedure C2 to be executed, then D2, then E, F2, H2, and
  1466.       finally I1.  Any procedure may terminate the processing which
  1467.       occurs or cause a state change.  Note that these procedures are
  1468.       executed in sequence, first C2, then D2, etc.  The time ordering
  1469.       cannot be mixed.
  1470.  
  1471.       The particular actions associated with each procedure are now
  1472.       described.
  1473.  
  1474.  
  1475.  
  1476.  
  1477.  
  1478.  
  1479.  
  1480.  
  1481. Finn                                                           [Page 26]
  1482.  
  1483.  
  1484.  
  1485. RFC 916                                                     October 1984
  1486. Reliable Asynchronous Transfer Protocol
  1487.  
  1488.  
  1489.       A  --------------------------------------------------------
  1490.  
  1491.          This procedure details the behavior of the LISTEN state.  First
  1492.          check the packet for the RST flag.  If it is set then packet is
  1493.          discarded and ignored, return and continue the processing
  1494.          associated with this state.
  1495.  
  1496.          We assume now that the RST flag was not set.  Check the packet
  1497.          for the ACK flag.  If it is set we have an illegal condition
  1498.          since no connection has yet been opened.  Send a RST packet
  1499.          with the correct response SN value:
  1500.  
  1501.             <SN=received AN><CTL=RST>
  1502.  
  1503.          Return to the current state without any further processing.
  1504.  
  1505.          We assume now that neither the RST nor the ACK flags were set.
  1506.          Check the packet for a SYN flag.  If it is set then an attempt
  1507.          is being made to open a connection.  Create a TCB for this
  1508.          connection.  The sender has placed its MDL in the LENGTH field,
  1509.          also specified is the sender's initial SN value.  Retrieve and
  1510.          place them into the TCB.  Note that the presence of the SO flag
  1511.          is ignored since it has no meaning when either of the SYN, RST,
  1512.          or FIN flags are set.
  1513.  
  1514.          Send a SYN packet which acknowledges the SYN received.  Choose
  1515.          the initial SN value and the MDL for this end of the
  1516.          connection:
  1517.  
  1518.             <SN=0><AN=received SN+1 modulo 2><CTL=SYN, ACK><LENGTH=MDL>
  1519.  
  1520.          and go to the SYN-RECEIVED state without any further
  1521.          processing.
  1522.  
  1523.          Any packet not satisfying the above tests is discarded and
  1524.          ignored.  Return to the current state without any further
  1525.          processing.
  1526.  
  1527.  
  1528.  
  1529.  
  1530.  
  1531.  
  1532.  
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538. Finn                                                           [Page 27]
  1539.  
  1540.  
  1541.  
  1542. RFC 916                                                     October 1984
  1543. Reliable Asynchronous Transfer Protocol
  1544.  
  1545.  
  1546.       B  --------------------------------------------------------
  1547.  
  1548.          This procedure represents the behavior of the SYN-SENT state
  1549.          and is entered when this end of the connection decides to
  1550.          execute an active OPEN.
  1551.  
  1552.          First, check the packet for the ACK flag.  If the ACK flag is
  1553.          set then check to see if the AN value was as expected.  If it
  1554.          was continue below.  Otherwise the AN value was unexpected.  If
  1555.          the RST flag was set then discard the packet and return to the
  1556.          current state without any further processing, else send a
  1557.          reset:
  1558.  
  1559.             <SN=received AN><CTL=RST>
  1560.  
  1561.          Discard the packet and return to the current state without any
  1562.          further processing.
  1563.  
  1564.          At this point either the ACK flag was set and the AN value was
  1565.          as expected or ACK was not set.  Second, check the RST flag.
  1566.          If the RST flag is set there are two cases:
  1567.  
  1568.             1. If the ACK flag is set then discard the packet, flush the
  1569.             retransmission queue, inform the user "Error: Connection
  1570.             refused", delete the TCB, and go to the CLOSED state without
  1571.             any further processing.
  1572.  
  1573.             2. If the ACK flag was not set then discard the packet and
  1574.             return to this state without any further processing.
  1575.  
  1576.          At this point we assume the packet contained an ACK which was
  1577.          Ok, or there was no ACK, and there was no RST.  Now check the
  1578.          packet for the SYN flag.  If the ACK flag was set then our SYN
  1579.          has been acknowledged.  Store MDL received in the TCB.  At this
  1580.          point we are technically in the ESTABLISHED state.  Send an
  1581.          acknowledgment packet and any initial data which is queued to
  1582.          send:
  1583.  
  1584.             <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK><DATA>
  1585.  
  1586.          Go to the ESTABLISHED state without any further processing.
  1587.  
  1588.          If the SYN flag was set but the ACK was not set then the other
  1589.          end of the connection has executed an active open also.
  1590.          Acknowledge the SYN, choose your MDL, and send:
  1591.  
  1592.             <SN=0><AN=received SN+1 modulo 2><CTL=SYN, ACK><LENGTH=MDL>
  1593.  
  1594.  
  1595. Finn                                                           [Page 28]
  1596.  
  1597.  
  1598.  
  1599. RFC 916                                                     October 1984
  1600. Reliable Asynchronous Transfer Protocol
  1601.  
  1602.  
  1603.          Go to the SYN-RECEIVED state without any further processing.
  1604.  
  1605.          Any packet not satisfying the above tests is discarded and
  1606.          ignored.  Return to the current state without any further
  1607.          processing.
  1608.  
  1609.       C1 --------------------------------------------------------
  1610.  
  1611.          Examine the received SN field value.  If the SN value was
  1612.          expected then return and continue the processing associated
  1613.          with this state.
  1614.  
  1615.          We now assume the SN value was not what was expected.
  1616.  
  1617.          If either RST or FIN were set discard the packet and return to
  1618.          the current state without any further processing.
  1619.  
  1620.          If neither RST nor FIN flags were set it is assumed that this
  1621.          packet is a duplicate of one already received.  Send an ACK
  1622.          back:
  1623.  
  1624.             <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
  1625.  
  1626.          Discard the duplicate packet and return to the current state
  1627.          without any further processing.
  1628.  
  1629.       C2 --------------------------------------------------------
  1630.  
  1631.          Examine the received SN field value.  If the SN value was
  1632.          expected then return and continue the processing associated
  1633.          with this state.
  1634.  
  1635.          We now assume the SN value was not what was expected.
  1636.  
  1637.          If either RST or FIN were set discard the packet and return to
  1638.          the current state without any further processing.
  1639.  
  1640.          If SYN was set we assume that the other end crashed and has
  1641.          attempted to open a new connection.  We respond by sending a
  1642.          legal reset:
  1643.  
  1644.             <SN=received AN><AN=received SN+1 modulo 2><CTL=RST, ACK>
  1645.  
  1646.          This will cause the other end, currently in the SYN-SENT state,
  1647.          to close.  Flush the retransmission queue, inform the user
  1648.          "Error: Connection reset", discard the packet, delete the TCB,
  1649.          and go to the CLOSED state without any further processing.
  1650.  
  1651.  
  1652. Finn                                                           [Page 29]
  1653.  
  1654.  
  1655.  
  1656. RFC 916                                                     October 1984
  1657. Reliable Asynchronous Transfer Protocol
  1658.  
  1659.  
  1660.          If neither RST, FIN, nor SYN flags were set it is assumed that
  1661.          this packet is a duplicate of one already received.  Send an
  1662.          ACK back:
  1663.  
  1664.             <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
  1665.  
  1666.          Discard the duplicate packet and return to the current state
  1667.          without any further processing.
  1668.  
  1669.       D1 --------------------------------------------------------
  1670.  
  1671.          The packet is examined for a RST flag.  If RST is not set then
  1672.          return and continue the processing associated with this state.
  1673.  
  1674.          RST is now assumed to have been set.  If the connection was
  1675.          originally initiated from the LISTEN state (it was passively
  1676.          opened) then flush the retransmission queue, discard the
  1677.          packet, and go to the LISTEN state without any further
  1678.          processing.
  1679.  
  1680.          If instead the connection was initiated actively (came from the
  1681.          SYN-SENT state) then flush the retransmission queue, inform the
  1682.          user "Error: Connection refused", discard the packet, delete
  1683.          the TCB, and go to the CLOSED state without any further
  1684.          processing.
  1685.  
  1686.       D2 --------------------------------------------------------
  1687.  
  1688.          The packet is examined for a RST flag.  If RST is not set then
  1689.          return and continue the processing associated with this state.
  1690.  
  1691.          RST is now assumed to have been set.  Any data remaining to be
  1692.          sent is flushed.  The retransmission queue is flushed, the user
  1693.          is informed "Error: Connection reset.", discard the packet,
  1694.          delete the TCB, and go to the CLOSED state without any further
  1695.          processing.
  1696.  
  1697.       D3 --------------------------------------------------------
  1698.  
  1699.          The packet is examined for a RST flag.  If RST is not set then
  1700.          return and continue the processing associated with this state.
  1701.  
  1702.          RST is now assumed to have been set.  Discard the packet,
  1703.          delete the TCB, and go to the CLOSED state without any further
  1704.          processing.
  1705.  
  1706.  
  1707.  
  1708.  
  1709. Finn                                                           [Page 30]
  1710.  
  1711.  
  1712.  
  1713. RFC 916                                                     October 1984
  1714. Reliable Asynchronous Transfer Protocol
  1715.  
  1716.  
  1717.       E  --------------------------------------------------------
  1718.  
  1719.          Check the presence of the SYN flag.  If the SYN flag is not set
  1720.          then return and continue the processing associated with this
  1721.          state.
  1722.  
  1723.          We now assume that the SYN flag was set.  The presence of a SYN
  1724.          here is an error.  Flush the retransmission queue, send a legal
  1725.          RST packet.
  1726.  
  1727.             If the ACK flag was set then send:
  1728.  
  1729.                <SN=received AN><CTL=RST>
  1730.  
  1731.             If the ACK flag was not set then send:
  1732.  
  1733.                <SN=0><CTL=RST>
  1734.  
  1735.          The user should receive the message "Error: Connection reset.",
  1736.          then delete the TCB and go to the CLOSED state without any
  1737.          further processing.
  1738.  
  1739.       F1 --------------------------------------------------------
  1740.  
  1741.          Check the presence of the ACK flag.  If ACK is not set then
  1742.          discard the packet and return without any further processing.
  1743.  
  1744.          We now assume that the ACK flag was set.  If the AN field value
  1745.          was as expected then return and continue the processing
  1746.          associated with this state.
  1747.  
  1748.          We now assume that the ACK flag was set and that the AN field
  1749.          value was unexpected.  If the connection was originally
  1750.          initiated from the LISTEN state (it was passively opened) then
  1751.          flush the retransmission queue, discard the packet, and send a
  1752.          legal RST packet:
  1753.  
  1754.             <SN=received AN><CTL=RST>
  1755.  
  1756.          Then delete the TCB and go to the LISTEN state without any
  1757.          further processing.
  1758.  
  1759.          Otherwise the connection was initiated actively (came from the
  1760.          SYN-SENT state) then inform the user "Error: Connection
  1761.          refused", flush the retransmission queue, discard the packet,
  1762.          and send a legal RST packet:
  1763.  
  1764.  
  1765.  
  1766. Finn                                                           [Page 31]
  1767.  
  1768.  
  1769.  
  1770. RFC 916                                                     October 1984
  1771. Reliable Asynchronous Transfer Protocol
  1772.  
  1773.  
  1774.             <SN=received AN><CTL=RST>
  1775.  
  1776.          Then delete the TCB and go to the CLOSED state without any
  1777.          further processing.
  1778.  
  1779.       F2 --------------------------------------------------------
  1780.  
  1781.          Check the presence of the ACK flag.  If ACK is not set then
  1782.          discard the packet and return without any further processing.
  1783.  
  1784.          We now assume that the ACK flag was set.  If the AN field value
  1785.          was as expected then flush the retransmission queue and inform
  1786.          the user with an "Ok" if a buffer has been entirely
  1787.          acknowledged.  Another packet containing data may now be sent.
  1788.          Return and continue the processing associated with this state.
  1789.  
  1790.          We now assume that the ACK flag was set and that the AN field
  1791.          value was unexpected.  This is assumed to indicate a duplicate
  1792.          acknowledgment.  It is ignored, return and continue the
  1793.          processing associated with this state.
  1794.  
  1795.       F3 --------------------------------------------------------
  1796.  
  1797.          Check the presence of the ACK flag.  If ACK is not set then
  1798.          discard the packet and return without any further processing.
  1799.  
  1800.          We now assume that the ACK flag was set.  If the AN field value
  1801.          was as expected then continue the processing associated with
  1802.          this state.
  1803.  
  1804.          We now assume that the ACK flag was set and that the AN field
  1805.          value was unexpected.  This is ignored, return and continue
  1806.          with the processing associated with this state.
  1807.  
  1808.       G  --------------------------------------------------------
  1809.  
  1810.          This procedure represents the behavior of the CLOSED state of a
  1811.          connection.  All incoming packets are discarded.  If the packet
  1812.          had the RST flag set take no action.  Otherwise it is necessary
  1813.          to build a RST packet.  Since this end is closed the other end
  1814.          of the connection has incorrect data about the state of the
  1815.          connection and should be so informed.
  1816.  
  1817.             If the ACK flag was set then send:
  1818.  
  1819.                <SN=received AN><CTL=RST>
  1820.  
  1821.  
  1822.  
  1823. Finn                                                           [Page 32]
  1824.  
  1825.  
  1826.  
  1827. RFC 916                                                     October 1984
  1828. Reliable Asynchronous Transfer Protocol
  1829.  
  1830.  
  1831.             If the ACK flag was not set then send:
  1832.  
  1833.                <SN=0><AN=received SN+1 modulo 2><CTL=RST, ACK>
  1834.  
  1835.          After sending the reset packet return to the current state
  1836.          without any further processing.
  1837.  
  1838.       H1 --------------------------------------------------------
  1839.  
  1840.          Our SYN has been acknowledged.  At this point we are
  1841.          technically in the ESTABLISHED state.  Send any initial data
  1842.          which is queued to send:
  1843.  
  1844.             <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK><DATA>
  1845.  
  1846.          Go to the ESTABLISHED state and execute procedure I1 to process
  1847.          any data which might be in this packet.
  1848.  
  1849.          Any packet not satisfying the above tests is discarded and
  1850.          ignored.  Return to the current state without any further
  1851.          processing.
  1852.  
  1853.       H2 --------------------------------------------------------
  1854.  
  1855.          Check the presence of the FIN flag.  If FIN is not set then
  1856.          continue the processing associated with this state.
  1857.  
  1858.          We now assume that the FIN flag was set.  This means the other
  1859.          end has decided to close the connection.  Flush the
  1860.          retransmission queue.  If any data remains to be sent then
  1861.          inform the user "Warning: Data left unsent."  The user must
  1862.          also be informed "Connection closing."  An acknowledgment for
  1863.          the FIN must be sent which also indicates this end is closing:
  1864.  
  1865.             <SN=received AN><AN=received SN + 1 modulo 2><CTL=FIN, ACK>
  1866.  
  1867.          Go to the LAST-ACK state without any further processing.
  1868.  
  1869.  
  1870.  
  1871.  
  1872.  
  1873.  
  1874.  
  1875.  
  1876.  
  1877.  
  1878.  
  1879.  
  1880. Finn                                                           [Page 33]
  1881.  
  1882.  
  1883.  
  1884. RFC 916                                                     October 1984
  1885. Reliable Asynchronous Transfer Protocol
  1886.  
  1887.  
  1888.       H3 --------------------------------------------------------
  1889.  
  1890.          This state represents the final behavior of the FIN-WAIT state.
  1891.  
  1892.          If the packet did not contain a FIN we assume this packet is a
  1893.          duplicate and that the other end of the connection has not seen
  1894.          the FIN packet we sent earlier.  Rely upon retransmission of
  1895.          our earlier FIN packet to inform the other end of our desire to
  1896.          close.  Discard the packet and return without any further
  1897.          processing.
  1898.  
  1899.          At this point we have a packet which should contain a FIN.  By
  1900.          the rules of this protocol an ACK of a FIN requires a FIN, ACK
  1901.          in response and no data.  If the packet contains data we have
  1902.          detected an illegal condition.  Send a reset:
  1903.          <SN=received AN><AN=received SN+1 modulo 2><CTL=RST, ACK>
  1904.  
  1905.          Discard the packet, flush the retransmission queue, inform the
  1906.          user "Error: Connection reset.", delete the TCB, and go to the
  1907.          CLOSED state without any further processing.
  1908.  
  1909.          We now assume that the FIN flag was set and no data was
  1910.          contained in the packet.  If the AN field value was expected
  1911.          then this packet acknowledges a previously sent FIN packet.
  1912.          The other end of the connection is then also assumed to be
  1913.          closing and expects an acknowledgment.  Send an acknowledgment
  1914.          of the FIN:
  1915.  
  1916.             <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
  1917.  
  1918.          Start the 2*SRTT timer associated with the TIME-WAIT state,
  1919.          discard the packet, and go to the TIME-WAIT state without any
  1920.          further processing.
  1921.  
  1922.          Otherwise the AN field value was unexpected.  This indicates a
  1923.          simultaneous closing by both sides of the connection.  Send an
  1924.          acknowledgment of the FIN:
  1925.  
  1926.             <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
  1927.  
  1928.          Discard the packet, and go to the CLOSING state without any
  1929.          further processing.
  1930.  
  1931.  
  1932.  
  1933.  
  1934.  
  1935.  
  1936.  
  1937. Finn                                                           [Page 34]
  1938.  
  1939.  
  1940.  
  1941. RFC 916                                                     October 1984
  1942. Reliable Asynchronous Transfer Protocol
  1943.  
  1944.  
  1945.       H4 --------------------------------------------------------
  1946.  
  1947.          This state represents the final behavior of the LAST-ACK state.
  1948.  
  1949.          If the AN field value is expected then this ACK is in response
  1950.          to the FIN, ACK packet recently sent.  This is the final
  1951.          acknowledging message indicating both side's agreement to close
  1952.          the connection.  Discard the packet, flush all queues, delete
  1953.          the TCB, and go to the CLOSED state without any further
  1954.          processing.
  1955.  
  1956.          Otherwise the AN field value was unexpected.  Discard the
  1957.          packet and remain in the current state without any further
  1958.          processing.
  1959.  
  1960.       H5 --------------------------------------------------------
  1961.  
  1962.          This state represents the final behavior of the CLOSING state.
  1963.  
  1964.          If the AN field value was expected then this packet
  1965.          acknowledges the FIN packet recently sent.  This is the final
  1966.          acknowledging message indicating both side's agreement to close
  1967.          the connection.  Start the 2*SRTT timer associated with the
  1968.          TIME-WAIT state, discard the packet, and go to the TIME-WAIT
  1969.          state without any further processing.
  1970.  
  1971.          Otherwise the AN field value was unexpected.  Discard the
  1972.          packet and remain in the current state without any further
  1973.          processing.
  1974.  
  1975.       H6 --------------------------------------------------------
  1976.  
  1977.          This state represents the behavior of the TIME-WAIT state.
  1978.          Check the presence of the ACK flag.  If ACK is not set then
  1979.          discard the packet and return without any further processing.
  1980.  
  1981.          Check the presence of the FIN flag.  If FIN is not set then
  1982.          discard the packet and return without any further processing.
  1983.  
  1984.          We now assume that the FIN flag was set.  This situation
  1985.          indicates that the last acknowledgment of the FIN packet sent
  1986.          by the other end of the connection did not arrive.  Resend the
  1987.          acknowledgment:
  1988.  
  1989.             <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
  1990.  
  1991.  
  1992.  
  1993.  
  1994. Finn                                                           [Page 35]
  1995.  
  1996.  
  1997.  
  1998. RFC 916                                                     October 1984
  1999. Reliable Asynchronous Transfer Protocol
  2000.  
  2001.  
  2002.          Restart the 2*SRTT timer, discard the packet, and remain in the
  2003.          current state without any further processing.
  2004.  
  2005.       I1 --------------------------------------------------------
  2006.  
  2007.          This represents that stage of processing in the ESTABLISHED
  2008.          state in which all the flag bits have been processed and only
  2009.          data may remain.  The packet is examined to see if it contains
  2010.          data.  If not the packet is now discarded, return to the
  2011.          current state without any further processing.
  2012.  
  2013.          We assume the packet contained data, that either the SO flag
  2014.          was set or LENGTH is positive.  That data is placed into the
  2015.          user's receive buffers.  As these become full the user should
  2016.          be informed "Receive buffer full."  An acknowledgment is sent:
  2017.  
  2018.             <SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
  2019.  
  2020.          If data is queued to send then it is most efficient to
  2021.          'piggyback' this acknowledgment on that data packet.
  2022.  
  2023.          The packet is now discarded, return to the ESTABLISHED state
  2024.          without any further processing.
  2025.  
  2026.    5.4. Timers
  2027.  
  2028.       There are three timers associated with this protocol.  Their
  2029.       purpose will now be briefly discussed as will the actions taken
  2030.       when a timer expires.  The particular nature these timeouts take
  2031.       and the methods by which they are set is the responsibility of the
  2032.       protocol implementation.
  2033.  
  2034.       5.4.1. User Timeout
  2035.  
  2036.          For practical implementation reasons it is desirable to have a
  2037.          user controllable timeout associated with the successful
  2038.          opening of a connection, successful acknowledgment of data, and
  2039.          successful closing of a connection.  Consider the situations in
  2040.          which a connection is so noisy that no data gets through, or a
  2041.          connection is physically cut.  Without an overriding timeout
  2042.          these situations would result in unbounded retransmissions.
  2043.  
  2044.          When this timeout expires the user is informed "Error:
  2045.          Connection aborted due to user timeout.", all queues are
  2046.          flushed, the TCB is deleted, and the CLOSED state is entered.
  2047.  
  2048.  
  2049.  
  2050.  
  2051. Finn                                                           [Page 36]
  2052.  
  2053.  
  2054.  
  2055. RFC 916                                                     October 1984
  2056. Reliable Asynchronous Transfer Protocol
  2057.  
  2058.  
  2059.       5.4.2. Retransmission Timeout
  2060.  
  2061.          This timer ensures that any packet sent for which the SN is
  2062.          significant is acknowledged.  When such a packet is sent it is
  2063.          placed in a retransmission queue and the retransmission timer
  2064.          is begun.  If an acknowledgment has not arrived within the
  2065.          timer's period then the packet is retransmitted and the timer
  2066.          is restarted.  If the acknowledgment does arrive in time then
  2067.          the timer is stopped and the packet is removed from the
  2068.          retransmission queue.  The next packet with a significant SN
  2069.          may now be sent.
  2070.  
  2071.          This timeout is expected to operate in conjunction with a
  2072.          counter which keeps track of the number of times a packet has
  2073.          been retransmitted.  Normally an upper limit is set on
  2074.          retransmissions.  If that limit is exceeded then the connection
  2075.          is aborted.  This event is similar to the user timeout.  The
  2076.          user is informed "Error: Connection aborted due to
  2077.          retransmission failure", all queues are flushed, the TCB is
  2078.          deleted, and the CLOSED state is entered.
  2079.  
  2080.       5.4.3. TIME-WAIT Timeout
  2081.  
  2082.          This timeout is used to catch any FIN packets which might be
  2083.          retransmitted from the other end of a connection in response to
  2084.          a dropped acknowledgment packet.  The timeout period should be
  2085.          at least as long as 2*SRTT.  After this timeout expires the
  2086.          other end of the connection is assumed to be closed, the TCB is
  2087.          deleted, and this end enters the CLOSED state also.
  2088.  
  2089.  
  2090.  
  2091.  
  2092.  
  2093.  
  2094.  
  2095.  
  2096.  
  2097.  
  2098.  
  2099.  
  2100.  
  2101.  
  2102.  
  2103.  
  2104.  
  2105.  
  2106.  
  2107.  
  2108. Finn                                                           [Page 37]
  2109.  
  2110.  
  2111.  
  2112. RFC 916                                                     October 1984
  2113. Reliable Asynchronous Transfer Protocol
  2114.  
  2115.  
  2116. 6. Data Error Handling
  2117.  
  2118.    This chapter discusses in detail the types of data errors an
  2119.    established connection may encounter.  These are distinct from
  2120.    protocol errors discussed above.  In order of discussion these are:
  2121.  
  2122.       - Framing Errors
  2123.  
  2124.       - Missing SYNCH pattern
  2125.  
  2126.       - Unacknowledged packets
  2127.  
  2128.       - Bad packets
  2129.  
  2130.       - Duplicate packets
  2131.  
  2132.       - Outside flow control
  2133.  
  2134.       - Packets that are too large
  2135.  
  2136.       - Packets that are too small
  2137.  
  2138.    6.1. Framing Errors
  2139.  
  2140.       The RS-232 specification provides framing only for an individual
  2141.       octet.  Link level protocols for computer networking normally
  2142.       provide framing for each packet.  The SYNCH pattern provides a
  2143.       boundary for the beginning of a packet.  No similar pattern was
  2144.       chosen to mark the end and completely frame the packet.
  2145.  
  2146.       Any bit pattern can appear in the data portion of a packet.  For
  2147.       any particular pattern to reliably mark the end of a packet that
  2148.       terminating pattern cannot be allowed to appear in the data.  This
  2149.       is usually accomplished by the sender altering any occurrence of
  2150.       the terminating pattern in the data so that it is both no longer
  2151.       recognizable as that pattern and also restorable upon receipt.
  2152.       Both the sender and the receiver are required by this technique to
  2153.       examine all the data.  In the absence of a protocol chip to
  2154.       perform this function, it is a source of some overhead.
  2155.  
  2156.       6.1.1. Synthetic Framing
  2157.  
  2158.          In the absence of framing, the end of the packet must be
  2159.          synthetically determined.  The start of a packet is indicated
  2160.          by the SYNCH pattern.  The expected end of a packet can now
  2161.          only be determined by examining the LENGTH octet of the header.
  2162.          It is important to know whether or not the LENGTH data can be
  2163.  
  2164.  
  2165. Finn                                                           [Page 38]
  2166.  
  2167.  
  2168.  
  2169. RFC 916                                                     October 1984
  2170. Reliable Asynchronous Transfer Protocol
  2171.  
  2172.  
  2173.          trusted.  This is accomplished by employing a one octet header
  2174.          checksum to cover the first two octets following the SYNCH
  2175.          pattern.  If the header passes the checksum test and neither
  2176.          the SYN, FIN, RST, nor SO flag bits were set then LENGTH is
  2177.          trusted and the number of octets expected beyond the header is
  2178.          LENGTH+2. (For those packets in which any of the above flag
  2179.          bits are set the packet length is fixed and includes only a
  2180.          header portion.)
  2181.  
  2182.          If the header fails the checksum test we are in some
  2183.          difficulty.  The length is incorrect so it may be too small or
  2184.          too large.  To recover from this error do the following.
  2185.          Beginning immediately after the SYNCH pattern rescan looking
  2186.          for the next SYNCH pattern.  Throw away all octets until a
  2187.          SYNCH is seen and then attempt to reinterpret it as a packet.
  2188.          The sender's retransmission timeout guarantees that a new copy
  2189.          of the packet will be transmitted.  This ensures that in
  2190.          discarding the initial SYNCH pattern, the SYNCH pattern from
  2191.          the beginning of the retransmitted packet will eventually be
  2192.          seen.
  2193.  
  2194.       6.1.2. Costs of Synthetic Framing
  2195.  
  2196.          This framing strategy causes no overhead unless data errors
  2197.          occur in the packet.  This is presumed to be a low probability
  2198.          occurrence.  In addition it removes the overhead of both sender
  2199.          and receiver passing over the data to process any termination
  2200.          pattern which might appear in the data.
  2201.  
  2202.          The worst case behavior would require a packet header to fail
  2203.          its checksum, a new SYNCH pattern to appear in the next few
  2204.          octets, that header failing its checksum, etc., until the SYNCH
  2205.          pattern of the retransmitted packet were finally seen.
  2206.          Consistently bad behavior of this type indicates an extremely
  2207.          noisy communications link.
  2208.  
  2209.    6.2. Missing SYNCH Pattern
  2210.  
  2211.       Any valid packet must begin with the SYNCH pattern.  Any receiver
  2212.       must discard all input octets until the SYNCH pattern is seen.
  2213.       The data which immediately follows a SYNCH pattern is interpreted
  2214.       as a packet.  The header checksum test is applied, then LENGTH+2
  2215.       octets are read, the data checksum test is applied, etc.
  2216.  
  2217.  
  2218.  
  2219.  
  2220.  
  2221.  
  2222. Finn                                                           [Page 39]
  2223.  
  2224.  
  2225.  
  2226. RFC 916                                                     October 1984
  2227. Reliable Asynchronous Transfer Protocol
  2228.  
  2229.  
  2230.    6.3. Unacknowledged Packets
  2231.  
  2232.       If an ACK for a packet is not obtained within the retransmission
  2233.       timeout interval that packet is retransmitted.  Because
  2234.       significant variability in response can be expected from either
  2235.       end of a connection it is best to dynamically calculate the
  2236.       retransmission timeout interval.  An example of such a calculation
  2237.       is provided below.  The protocol will operate successfully,
  2238.       although not with as high an effective transmission rate, if a
  2239.       realistic upper bound time is used instead.
  2240.  
  2241.       A realistic upper bound time depends upon the packet size and line
  2242.       speed.  If the baud rate of the connection is 300 or above let B
  2243.       be the baud rate (for clarity assume it is the same in both
  2244.       directions), let L be the MDL of the receiver, let P be the packet
  2245.       processing time of the receiver.  Then an Upper Bound for the
  2246.       Reception Time (UBRT) is:
  2247.  
  2248.          UBRT = L/(B/10) seconds + P seconds
  2249.  
  2250.       and a realistic upper bound time is 2*UBRT seconds.
  2251.  
  2252.       6.3.1. Calculation of Retransmission Timeout Interval
  2253.  
  2254.          For the purpose of detecting retransmission time out the
  2255.          protocol must have access to a clock which provides at least
  2256.          single second resolution.  One technique for calculating the
  2257.          round trip time is:
  2258.  
  2259.             Measure the elapsed time between sending a packet with a
  2260.             particular SN and receiving an ACK with an AN which covers
  2261.             that SN.  The measured elapsed time is the Round Trip Time
  2262.             (RTT).  Next a Smoothed Round Trip Time (SRTT) is calculated
  2263.             as:
  2264.  
  2265.                SRTT = (ALPHA * SRTT) + ((1- ALPHA) * RTT)
  2266.  
  2267.             and based upon this you compute the Retransmission Time Out
  2268.             (RTO) as:
  2269.  
  2270.                RTO = min[UBOUND, max[LBOUND, (BETA * SRTT)]]
  2271.  
  2272.             where UBOUND is an upper bound on the timeout (e.g., 1
  2273.             minute), LBOUND is a lower bound on the timeout (e.g., 1
  2274.             second), ALPHA is a smoothing factor (e.g., .8 to .9), and
  2275.             BETA is a delay variance factor (e.g., 1.3 to 2.0).
  2276.  
  2277.  
  2278.  
  2279. Finn                                                           [Page 40]
  2280.  
  2281.  
  2282.  
  2283. RFC 916                                                     October 1984
  2284. Reliable Asynchronous Transfer Protocol
  2285.  
  2286.  
  2287.    6.4. Bad Packets
  2288.  
  2289.       A bad packet is received when it fails either the header or data
  2290.       checksum tests.  When this happens the sender will retransmit the
  2291.       packet after the retransmission timeout interval.
  2292.  
  2293.    6.5. Duplicate Packets
  2294.  
  2295.       A duplicate packet is a packet which passes the checksum tests but
  2296.       for which the SN received is significant but not the expected
  2297.       value.  This is normally caused when the sender did not get the
  2298.       ACK last sent by the receiver.  This situation is diagrammed
  2299.       below.
  2300.  
  2301.       Side A                                             Side B
  2302.  
  2303.       ESTABLISHED                                        ESTABLISHED
  2304.  
  2305.       1.      --> <SN=1><AN=0><CTL=ACK><DATA>       ...
  2306.                                                     -->
  2307.  
  2308.       2.      XXX <SN=0><AN=0><CTL=ACK><OTHER-DATA> <--
  2309.  
  2310.       3. (after SRTT)
  2311.               --> <SN=1><AN=0><CTL=ACK><DATA>       ...
  2312.  
  2313.       4.                                            -->
  2314.               ... <SN=0><AN=0><CTL=ACK><OTHER-DATA> <--
  2315.  
  2316.       5.      <--
  2317.  
  2318.       In line 2, B's packet was lost in transit, it may have failed its
  2319.       checksum tests when it reached A or its initial SYNCH pattern was
  2320.       smashed, etc..  In line 3 side A comes to the decision that its
  2321.       packet from line 1 was not received after SRTT time passes and
  2322.       retransmits that packet.
  2323.  
  2324.       In line 4 side B receives the packet.  It detects a duplicate
  2325.       because it already sent a packet acknowledging A's SN=1 (although
  2326.       that packet was lost).  B now discards the duplicate and
  2327.       immediately retransmits its last packet to A. Side A finally
  2328.       receives the retransmitted packet in line 5.
  2329.  
  2330.  
  2331.  
  2332.  
  2333.  
  2334.  
  2335.  
  2336. Finn                                                           [Page 41]
  2337.  
  2338.  
  2339.  
  2340. RFC 916                                                     October 1984
  2341. Reliable Asynchronous Transfer Protocol
  2342.  
  2343.  
  2344.    6.6. Outside Flow Control
  2345.  
  2346.       There are many large computer systems which make use of flow
  2347.       control to regulate their input side of an RS-232 link.  Flow
  2348.       control based upon two special characters such as <Ctrl-S> (ASCII
  2349.       DC3) and <Ctrl-Q> (ASCII DC1) is almost universally in use today.
  2350.       So it becomes important for the protocol to be able to either:
  2351.  
  2352.          (1) Recognize and obey the flow control of the host
  2353.              computer(s), or
  2354.  
  2355.          (2) Ignore the flow control but still guarantee reliable data
  2356.              reception.
  2357.  
  2358.       It is the latter approach which this protocol takes.  This
  2359.       decision was made because the number of differing flow control
  2360.       characters in use would make it difficult to obey them all.
  2361.  
  2362.          There is a particular type of flow control with which this
  2363.          protocol will not operate.  The ENQUIRE, ACKNOWLEDGE method of
  2364.          flow control requires that the receiver of an inquiry respond
  2365.          with an acknowledge before any more data will be sent to it.
  2366.          This type of flow control also usually prohibits unrestricted
  2367.          8-bit data transmission because the inquiry character is
  2368.          forbidden as a data byte.
  2369.  
  2370.       For the other class of flow control methods a proof is required
  2371.       that data may still be reliably transmitted and received if flow
  2372.       control is ignored.  For the purposes of this discussion assume
  2373.       <Ctrl-S> is sent when the receiving end of the connection wishes
  2374.       the sender to stop transmitting.  A <Ctrl-Q> is sent when the
  2375.       receiver wishes the sender to resume.  The choice of these
  2376.       particular two characters is arbitrary.  If the sender does not
  2377.       immediately cease transmission upon receipt of the <Ctrl-S>,
  2378.       characters may be discarded.  Since this protocol chooses to
  2379.       ignore the flow control characters any part of a packet may be
  2380.       discarded.
  2381.  
  2382.       More precisely stated consider X to be the receiver and Y to be
  2383.       the sender.  The packet sent is represented by the string abc
  2384.       where a, b, and c are data segments of unspecified size.  X may
  2385.       receive one of:
  2386.  
  2387.          1. abc
  2388.          2. ab
  2389.          3. ac
  2390.          4. bc
  2391.  
  2392.  
  2393. Finn                                                           [Page 42]
  2394.  
  2395.  
  2396.  
  2397. RFC 916                                                     October 1984
  2398. Reliable Asynchronous Transfer Protocol
  2399.  
  2400.  
  2401.       For case [1] the correct data is received and no special action
  2402.       need be taken.
  2403.  
  2404.       For cases [2], [3], and [4] we have a situation identical to data
  2405.       dropped during transmission.  This is handled by the same
  2406.       checksum, time-out and retransmission strategy already described.
  2407.  
  2408.       Assume Y is not now in the act of receiving a packet, then Y sees
  2409.       the two characters <Ctrl-S> and <Ctrl-Q> appear as input in that
  2410.       order.  Y is waiting for a message to appear and so expects to see
  2411.       a SYNCH pattern.  If the two characters "<Ctrl-S><Ctrl-Q>" are not
  2412.       part of a SYNCH pattern then they will be immediately discarded.
  2413.       If Y is receiving a packet then the <Ctrl-S> and <Ctrl-Q> are seen
  2414.       to be added noise characters and would be detected by the checksum
  2415.       tests.  The packet being received would require retransmission.
  2416.  
  2417.       The question of which character to pick for the SYNCH pattern is
  2418.       slightly muddied by the above observation.  To the author's
  2419.       knowledge <SOH> is rarely if ever picked for flow control.  This
  2420.       is part of the motivation in using it as the SYNCH pattern.
  2421.  
  2422.       How does one guarantee that any data will actually arrive
  2423.       successfully?  The initial choice of maximum data counts during
  2424.       connection establishment is very important.  Some knowledge of
  2425.       one's own operating system must be assumed.  If it is known for
  2426.       example, that streams of data in excess of a certain length will
  2427.       often trigger flow control at the connection baud rate, then the
  2428.       maximum data count should be chosen sufficiently lower that flow
  2429.       control rarely will be employed.  An intelligent choice of the
  2430.       maximum data count will guarantee that some packets will arrive
  2431.       without encountering flow control.
  2432.  
  2433.    6.7. Packets that are too Large
  2434.  
  2435.       Assume a packet arrives which passes its header checksum test but
  2436.       whose LENGTH is larger than the MDL of the receiver.  In such a
  2437.       case the sender has violated the protocol or a packet has a data
  2438.       error in the LENGTH octet and has passed the header checksum test.
  2439.       The latter is unlikely so that we assume the former.  The receiver
  2440.       will abort his connection.  The sender must inform the user
  2441.       "Error: Connection aborted due to MDL error", and go to the CLOSED
  2442.       state.
  2443.  
  2444.       When the MDL is exceeded the receiver will transmit a legal reset:
  2445.  
  2446.          <SN=received AN><CTL=RST>
  2447.  
  2448.  
  2449.  
  2450. Finn                                                           [Page 43]
  2451.  
  2452.  
  2453.  
  2454. RFC 916                                                     October 1984
  2455. Reliable Asynchronous Transfer Protocol
  2456.  
  2457.  
  2458.    6.8. Packets that are too Small
  2459.  
  2460.       Assume that a packet has passed its header checksum test but some
  2461.       of the data octets have been dropped by the link.  In such a case
  2462.       the receiver's routine which reads data and builds packets is
  2463.       expecting octets which do not arrive.  After SRTT the sender will
  2464.       retransmit this packet to the receiver.  The receiver will now
  2465.       have enough data to complete the packet.  Almost certainly however
  2466.       it will fail the data checksum test.  As with any bad packet the
  2467.       receiver will rescan from the octet immediately following the
  2468.       SYNCH pattern for the next SYNCH pattern.  In this manner the
  2469.       receiver will eventually see the SYNCH pattern of the
  2470.       retransmitted packet.
  2471.  
  2472.  
  2473.  
  2474.  
  2475.  
  2476.  
  2477.  
  2478.  
  2479.  
  2480.  
  2481.  
  2482.  
  2483.  
  2484.  
  2485.  
  2486.  
  2487.  
  2488.  
  2489.  
  2490.  
  2491.  
  2492.  
  2493.  
  2494.  
  2495.  
  2496.  
  2497.  
  2498.  
  2499.  
  2500.  
  2501.  
  2502.  
  2503.  
  2504.  
  2505.  
  2506.  
  2507. Finn                                                           [Page 44]
  2508.  
  2509.  
  2510.  
  2511. RFC 916                                                     October 1984
  2512. Reliable Asynchronous Transfer Protocol
  2513.  
  2514.  
  2515. I.  Inability to Transmit/Receive 8-bit Data
  2516.  
  2517.    There are some older operating systems and devices which do not
  2518.    permit 8-bit communication over an RS-232 link.  Most of these allow
  2519.    restricted 7-bit communication.  Where this is an unavoidable problem
  2520.    both ends of the connection must have a protocol layer beneath this
  2521.    protocol.  This lower layer will unpack packets it sends over the
  2522.    RS-232 link.  It will also repack packets it receives over the RS-232
  2523.    link.  RATP will automatically determine whether or not full 8-bit or
  2524.    restricted 7-bit communication is being used (see below).
  2525.  
  2526.    The strategy chosen for restricted 7-bit communication is called 4/8
  2527.    packing.  That is, each octet to be sent will be broken up into two
  2528.    4-bit nibbles.  The order of transmission is the high order four bits
  2529.    followed by the low order bits.  Each octet to be received will be
  2530.    repacked by the inverse function.  The high order nibble will be
  2531.    received first then the low order nibble.  These two nibbles will be
  2532.    reassembled into an octet.
  2533.  
  2534.    I.1.  Encoding for Transmission
  2535.  
  2536.       For those systems which are incapable of 8-bit data transmission
  2537.       over RS-232 links, there are operating systems which in addition
  2538.       place special restrictions on the non-printable ASCII characters.
  2539.       The encoding for 4/8 packing should restrict itself to
  2540.       transmitting data only in the printable 7-bit ASCII range.
  2541.  
  2542.    I.2.  Framing an Octet
  2543.  
  2544.       The seventh and highest order bit of a transmitted 7-bit ASCII
  2545.       byte is a flag used to indicate whether the high or low order
  2546.       nibble of an octet is contained in this character.  This flag bit
  2547.       if set implies that a new octet is being received and that this
  2548.       printable ASCII character contains the high order nibble of an
  2549.       octet in its four low order bits.  In addition it implies the next
  2550.       ASCII character received should not have its highest order bit
  2551.       set.
  2552.  
  2553.       This high order flag bit is set by adding the ASCII character "@"
  2554.       (octal 100) to a data byte.  Thus the first nibble of an octet is
  2555.       always transmitted with "@" added to its value.  The high order
  2556.       nibble will be transformed into the characters "@" through letter
  2557.       "O".
  2558.  
  2559.       The lower order nibble of an octet is transmitted with zero "0"
  2560.       added to its value.  The low order nibble will be transformed into
  2561.  
  2562.  
  2563.  
  2564. Finn                                                           [Page 45]
  2565.  
  2566.  
  2567.  
  2568. RFC 916                                                     October 1984
  2569. Reliable Asynchronous Transfer Protocol
  2570.  
  2571.  
  2572.       characters "0" through "?".  When receiving 4/8 packed data, any
  2573.       characters not within the range "0" through letter "O" are
  2574.       discarded.
  2575.  
  2576.       The octet whose octal value is 45 will be transmitted as two 7-bit
  2577.       printable ASCII characters:
  2578.  
  2579.                  +-------------+
  2580.       High order |1|0|0|0|1|0|0| First transmitted ("@" + data) = D
  2581.                  +-------------+
  2582.       Low order  |0|1|1|0|1|0|1| Second transmitted ("0" + data) = 5
  2583.                  +-------------+
  2584.  
  2585.       Since data bytes may be dropped or added at any time it is
  2586.       important to know always which portion of an octet is expected and
  2587.       to deliver only complete octets to the higher protocol level.  If
  2588.       a single 7-bit character were completely dropped without being
  2589.       noticed the data stream delivered to the higher level could be
  2590.       shifted by an odd multiple of four bits.  In the worst case this
  2591.       condition could remain indefinitely and the higher level would
  2592.       never receive an octet correctly.  In such a case no packets would
  2593.       be correctly received, leading to an unusable connection.
  2594.  
  2595.       To avoid this problem octets are assembled using a state machine
  2596.       driven by the presence of the high order flag bit.  The presence
  2597.       of that bit in the 7-bit printable character indicates the
  2598.       beginning of a new octet.  The two state machine which assembles
  2599.       octets is described below.  A byte received with the high order
  2600.       flag bit set is called "HIGH", the byte without "LOW".
  2601.  
  2602.          State 0
  2603.  
  2604.             [Start state] Read a byte from the legal restricted set.
  2605.             This is determined by seeing if the byte is in the legal
  2606.             range "@" to the letter "O".  If it was not discard the byte
  2607.             and return to this state.
  2608.  
  2609.             A HIGH byte was read.  Place the four low order bits of the
  2610.             byte into the four high order bits of the assembled octet
  2611.             and go to state 1.  Otherwise discard the byte and return to
  2612.             this state.
  2613.  
  2614.  
  2615.  
  2616.  
  2617.  
  2618.  
  2619.  
  2620.  
  2621. Finn                                                           [Page 46]
  2622.  
  2623.  
  2624.  
  2625. RFC 916                                                     October 1984
  2626. Reliable Asynchronous Transfer Protocol
  2627.  
  2628.  
  2629.          State 1
  2630.  
  2631.             Read a byte from the legal restricted set.  This is
  2632.             determined by seeing if the byte is in the legal range zero
  2633.             "0" to the letter "O".  If it was not discard the byte and
  2634.             return to this state.
  2635.  
  2636.             If a LOW byte was read subtract zero "0" from the byte
  2637.             placing the four low order bits of the result into the four
  2638.             low order bits of the assembled octet.  A full octet has now
  2639.             been assembled.  Pass the octet to the higher level and go
  2640.             to state 0.
  2641.  
  2642.             Otherwise a HIGH byte was read.  Place the four low order
  2643.             bits of the byte into the four high order bits of the
  2644.             assembled octet and return to this state.
  2645.  
  2646.       Utilizing this state machine to receive 4/8 packed data ensures
  2647.       that the data stream delivered to the higher level will not
  2648.       permanently remain shifted an odd multiple of four bits.  The
  2649.       restriction placed upon bytes read removes obviously bad data and
  2650.       in some cases would handle uncontrolled padding or blocking
  2651.       insertion.
  2652.  
  2653.    I.3.  Automatic Detection of 8-bit or 4/8 Packed Data
  2654.  
  2655.       It is an unavoidable problem that some machines cannot handle
  2656.       unrestricted 8-bit data.  Since this is given, it is desirable to
  2657.       be able to automatically detect whether unrestricted 8-bit or
  2658.       restricted 4/8 packing is being used to transmit data on a
  2659.       connection.  For the purposes of this discussion those machines
  2660.       capable of transmitting and receiving both unrestricted 8-bit and
  2661.       4/8 packed data are called smart.  Machines are called dumb if
  2662.       they can only transmit and receive 4/8 packed data.
  2663.  
  2664.       When initiating a connection there are four possible machine
  2665.       configurations and they are:
  2666.  
  2667.          1. A (smart) opens a connection to B (smart).
  2668.  
  2669.          2. A (dumb) opens a connection to B (smart).
  2670.  
  2671.          3. A (dumb) opens a connection to B (dumb).
  2672.  
  2673.          4. A (smart) opens a connection to B (dumb).
  2674.  
  2675.  
  2676.  
  2677.  
  2678. Finn                                                           [Page 47]
  2679.  
  2680.  
  2681.  
  2682. RFC 916                                                     October 1984
  2683. Reliable Asynchronous Transfer Protocol
  2684.  
  2685.  
  2686.       Each case is examined and extensions to the behavior for the
  2687.       LISTEN and SYN-SENT states are provided which allow both types of
  2688.       machines to initiate or receive a connection.
  2689.  
  2690.       Cases 1 and 2: LISTEN Behavior for a Smart Machine
  2691.  
  2692.          In these cases machine A initiates a connection to B who is
  2693.          assumed to be in the LISTEN state.  B must be able to passively
  2694.          detect whether 8-bit or 4/8 packing is being used and respond
  2695.          accordingly.  The method B uses relies upon the detection of a
  2696.          valid first packet.  In the LISTEN state B attempts to
  2697.          simultaneously treat the incoming data as if it were both
  2698.          unrestricted 8-bit and 4/8 packed.
  2699.  
  2700.          The incoming data is in effect fed to two different receiving
  2701.          algorithms.  The detection of a valid header will occur to one
  2702.          of these algorithms before the other.  If the first valid
  2703.          header was read assuming unrestricted 8-bit data then any
  2704.          resulting connection is assumed to use unrestricted 8-bit data
  2705.          for the life of the connection.  If the first valid header
  2706.          assumed 4/8 packing then the resulting connection is assumed to
  2707.          use 4/8 packing for the life of the connection.  In the case of
  2708.          the detection of illegal condition in the LISTEN state the
  2709.          protocol will reply with a RST packet in kind.
  2710.  
  2711.       Case 3: LISTEN Behavior for a Dumb Machine
  2712.  
  2713.          In this case machine B is the recipient of a connection request
  2714.          and is capable of handling only 4/8 packed data.  The LISTEN
  2715.          behavior for machine B assumes that all connections are 4/8
  2716.          packed.  It never deals with unrestricted 8-bit data.  As a
  2717.          result it will refuse to open a connection request from a smart
  2718.          machine (see case 4 below).
  2719.  
  2720.       Case 4: SYN-SENT Behavior for a Smart Machine
  2721.  
  2722.          In this case machine A attempts to open a connection to machine
  2723.          B. However, A has no knowledge of B's capabilities.  A will
  2724.          send its connection request assuming B is smart using
  2725.          unrestricted 8-bit transmission.  It will await a reply
  2726.          assuming the response will be unrestricted 8-bit also.  If B is
  2727.          in fact dumb it will not return a SYN-ACK because of the
  2728.          restriction imposed by case 3 above.  If no connection is made
  2729.          with B using 8-bit data the entire connection initiation is
  2730.          restarted assuming B is dumb, 4/8 packing is used and the
  2731.          response is assumed to be 4/8 packed as well.
  2732.  
  2733.  
  2734.  
  2735. Finn                                                           [Page 48]
  2736.  
  2737.  
  2738.  
  2739. RFC 916                                                     October 1984
  2740. Reliable Asynchronous Transfer Protocol
  2741.  
  2742.  
  2743.          The cost of this approach is a longer time to determine whether
  2744.          or not it is possible to open a connection to B. It is twice as
  2745.          long.  The advantages of being able to automatically adjust to
  2746.          either unrestricted 8-bit or 4/8 packed data out weigh this
  2747.          disadvantage.  RATP will not exhibit the schizophrenic behavior
  2748.          of many other asynchronous protocols when dealing with both
  2749.          classes of machines.
  2750.  
  2751.  
  2752.  
  2753.  
  2754.  
  2755.  
  2756.  
  2757.  
  2758.  
  2759.  
  2760.  
  2761.  
  2762.  
  2763.  
  2764.  
  2765.  
  2766.  
  2767.  
  2768.  
  2769.  
  2770.  
  2771.  
  2772.  
  2773.  
  2774.  
  2775.  
  2776.  
  2777.  
  2778.  
  2779.  
  2780.  
  2781.  
  2782.  
  2783.  
  2784.  
  2785.  
  2786.  
  2787.  
  2788.  
  2789.  
  2790.  
  2791.  
  2792. Finn                                                           [Page 49]
  2793.  
  2794.  
  2795.  
  2796. RFC 916                                                     October 1984
  2797. Reliable Asynchronous Transfer Protocol
  2798.  
  2799.  
  2800. II.  A Brief Survey of Some Asynchronous Link Protocols
  2801.  
  2802.    II.1.  DDCMP
  2803.  
  2804.       DDCMP, Copyright (c) 1978 Digital Equipment Corporation [DDCMP
  2805.       78], is a reliable point-to-point and multi-point transmission
  2806.       protocol is used by many of that manufacturer's computers.  DDCMP
  2807.       does provide reliable asynchronous two way data transmission.
  2808.  
  2809.       Some of the decisions taken in the design of DDCMP reflect its
  2810.       orientation toward multi-point data links.  This leads to headers
  2811.       which are substantially longer than needed for two way
  2812.       point-to-point communications.
  2813.  
  2814.       DDCMP allows as many as 255 outstanding unacknowledged messages.
  2815.       DDCMP does specifically mention that a particular end of a
  2816.       connection may choose to limit the send queue to one outstanding
  2817.       unacknowledged message.  It also allows sending a stream of
  2818.       outstanding unacknowledged packets.  Unless all RS-232
  2819.       implementations of DDCMP were limited to a single outstanding
  2820.       packet, the collision with existing flow control restrictions
  2821.       could lead to very low thruput. (DDCMP is assumed to have control
  2822.       over the link driver.  Dealing with various differing flow control
  2823.       mechanisms is not a consideration.)
  2824.  
  2825.       DDCMP uses a CRC polynomial for data protection which is difficult
  2826.       to calculate for many machines without special hardware [TCP
  2827.       Checksum 78].  Many Digital Equipment computers have such
  2828.       hardware.
  2829.  
  2830.       DDCMP does not provide the receiver with the ability to restrict
  2831.       incoming packet size.  It is true that all the higher level
  2832.       protocols built on top of DDCMP could separately negotiate packet
  2833.       size.  But this burden would then be moved away from the link
  2834.       level where it properly resides.
  2835.  
  2836.       Generally, a full implementation of DDCMP is too complex for
  2837.       consideration.  If one were to implement 'part' of the protocol
  2838.       then issues of compatibility with already existing implementations
  2839.       on other computers are raised.
  2840.  
  2841.  
  2842.  
  2843.  
  2844.  
  2845.  
  2846.  
  2847.  
  2848.  
  2849. Finn                                                           [Page 50]
  2850.  
  2851.  
  2852.  
  2853. RFC 916                                                     October 1984
  2854. Reliable Asynchronous Transfer Protocol
  2855.  
  2856.  
  2857.    II.2.  MODEM Protocol
  2858.  
  2859.       This is a protocol in common use amongst microcomputers.  The
  2860.       description here comes from
  2861.  
  2862.          MODEM/XMODEM Protocol Explained by Kelly Smith, CP/M-Net
  2863.          "SYSOP" January 8,1980
  2864.  
  2865.          .... Data is sent in 128-byte sequentially numbered blocks,
  2866.          with a single checksum byte appended to the end of each block.
  2867.          As the receiving computer acquires the incoming data, it
  2868.          performs its own checksum and upon each completion of a block,
  2869.          it compares its checksum result with that of the sending
  2870.          computers.  If the receiving computer matches the checksum of
  2871.          the sending computer, it transmits an ACK (ASCII code protocol
  2872.          character for ACKNOWLEDGE (06 Hex, Control-F)) back to the
  2873.          sending computer.  The ACK therefore means "all's well on this
  2874.          end, send some more...".
  2875.  
  2876.          The sending computer will transmit an "initial NAK" (ASCII
  2877.          protocol character for NEGATIVE ACKNOWLEDGE (15 Hex,
  2878.          Control-U))...or, "that wasn't quite right, please send again".
  2879.          Due to the asynchronous nature of the initial "hook-up" between
  2880.          the two computers, the receiving computer will "time-out"
  2881.          looking for data, and send the NAK as the "cue" for the sending
  2882.          computer to begin transmission.  The sending computer knows
  2883.          that the receiving computer will "time-out", and uses this fact
  2884.          to "get in sync"...  The sending computer responds to the
  2885.          "initial NAK" with a SOH (ASCII code protocol character for
  2886.          START OF HEADING (01 Hex, Control-A)), sends the first block
  2887.          number, sends the 1's complement of the block number, sends 128
  2888.          bytes of 8 bit data, and finally a checksum, where the checksum
  2889.          is calculated by summing the SOH, the block number, the block
  2890.          number 1's complement, and the 128 bytes of data.
  2891.  
  2892.          Receiving Computer:
  2893.  
  2894.             ---/NAK/------------------------/ACK/------------------
  2895.                 15H                          06H
  2896.  
  2897.          Sending Computer:
  2898.  
  2899.             ---/SOH/BLK#/BLK#/DATA/CSUM/---/SOH/BLK#/BLK#/DATA/etc.
  2900.                 01H 01H  FEH  8bit 8bit     01H 02H  FDH  8bit ....
  2901.  
  2902.  
  2903.  
  2904.  
  2905.  
  2906. Finn                                                           [Page 51]
  2907.  
  2908.  
  2909.  
  2910. RFC 916                                                     October 1984
  2911. Reliable Asynchronous Transfer Protocol
  2912.  
  2913.  
  2914.          This process continues, with the next 128 bytes.  If the block
  2915.          was ACK'ed by the receiving computer, and then the next
  2916.          sequential block number and its 1's complement, etc. ....
  2917.  
  2918.       As can be seen from this partial description the MODEM protocol is
  2919.       unidirectional, data can only pass from the sender to the receiver
  2920.       in a stream.  In order for data to flow simultaneously in the
  2921.       other direction another connection over another RS-232 line would
  2922.       be required.
  2923.  
  2924.       In addition this protocol is restricted to a fixed 128 octet
  2925.       packet size.  Many front-end concentrators are unable to service
  2926.       such large incoming packets.  It has been observed many times that
  2927.       the concentrator of a busy DECsystem-20 can invoke flow control on
  2928.       input at 1200 baud for packets as small as 64 characters.
  2929.  
  2930.    II.3.  KERMIT System
  2931.  
  2932.       The KERMIT system, Copyright (c) 1981 Columbia University, is a
  2933.       file transfer environment developed recently.  It has
  2934.       implementations which run on DECsystem-20, IBM 370 VM/CMS, 8080
  2935.       CP/M based systems, and the IBM PC among others.
  2936.  
  2937.       KERMIT combines both the reliable transfer and file transfer into
  2938.       a single package.  Extension to other applications and higher
  2939.       level protocols would be possible but the boundary between the
  2940.       reliable transfer and application layers is very indistinct.  It
  2941.       violates the layering design strategy the Internet employs.
  2942.  
  2943.       There is a limitation of transmission to the restricted printable
  2944.       ASCII set for certain computers but not for others.  This leads to
  2945.       confusion.  KERMIT allows both restricted ASCII and 8-bit
  2946.       transmission.
  2947.  
  2948.       The KERMIT protocol does have a method of setting MDL at
  2949.       connection initiation.  It is limited to a smaller maximum packet
  2950.       size, 96 as opposed to 261 octets.  Kermit originally used a
  2951.       checksumming algorithm limited to six bits.  This is considered to
  2952.       provide too low a level of error detection capability for data
  2953.       packets.  Kermit now allows two other checksumming algorithms in
  2954.       addition to the original.  There must be a negotiation between
  2955.       sender and receiver regarding which algorithm to use.
  2956.  
  2957.       The KERMIT protocol does not appear to make provision for both
  2958.       sides of a connection attempting an active open simultaneously.
  2959.       One side must be an initial "sending Kermit" and the other a
  2960.       "receiving Kermit".  The code published as a KERMIT implementation
  2961.  
  2962.  
  2963. Finn                                                           [Page 52]
  2964.  
  2965.  
  2966.  
  2967. RFC 916                                                     October 1984
  2968. Reliable Asynchronous Transfer Protocol
  2969.  
  2970.  
  2971.       guide cannot recover from simultaneous active opens, it
  2972.       immediately ABORTs.  This reflects a bias towards unidirectional
  2973.       data flow.
  2974.  
  2975.       The KERMIT packet type (similar to RATP control flags) specifies
  2976.       whether an ACK/NAK is contained in the packet, or data, etc.
  2977.       These are mutually exclusive and piggybacking an ACK on a data
  2978.       packet is not possible.  This can be a source of overhead.  In
  2979.       addition KERMIT restricts the sender to a single outstanding
  2980.       unacknowledged packet as does RATP.  It allocates an entire byte
  2981.       to the sequence number which is unnecessary.
  2982.  
  2983.       On the subject of error recovery, the size of a packet is
  2984.       contained in the second byte of the packet and is not protected by
  2985.       a header checksum.  If the length field was in error due to noise
  2986.       on the link, it could be longer than the correct packet size.  The
  2987.       code published as the KERMIT implementation guide relies upon the
  2988.       detection of the <SOH> character anywhere in a packet to indicate
  2989.       the beginning of a packet header.  It re-SYNCHs using this
  2990.       technique.  This is only possible if binary data in a packet is
  2991.       quoted.  If full eight bit data is transmitted it does not appear
  2992.       that the KERMIT protocol rescans for a new MARK (SYNCH) character
  2993.       within the bad packet data just consumed.  It will under these
  2994.       circumstances throw away the retransmitted packet or portions
  2995.       thereof.  Re-SYNCHing under such conditions is problematical.
  2996.  
  2997.  
  2998.  
  2999.  
  3000.  
  3001.  
  3002.  
  3003.  
  3004.  
  3005.  
  3006.  
  3007.  
  3008.  
  3009.  
  3010.  
  3011.  
  3012.  
  3013.  
  3014.  
  3015.  
  3016.  
  3017.  
  3018.  
  3019.  
  3020. Finn                                                           [Page 53]
  3021.  
  3022.  
  3023.  
  3024. RFC 916                                                     October 1984
  3025. Reliable Asynchronous Transfer Protocol
  3026.  
  3027.  
  3028. REFERENCES
  3029.  
  3030.    [Cohen 81]
  3031.  
  3032.       Cohen, D. On Holy Wars and a Plea for Peace. IEEE Computer,
  3033.       October, 1981.
  3034.  
  3035.    [DDCMP 78]
  3036.  
  3037.       DDCMP AA-D599A-TC edition, Digital Equipment Corporation, 1978.
  3038.       Version 4.0.
  3039.  
  3040.    [IP 81]
  3041.  
  3042.       Postel, J. DOD Standard Internet Protocol [RFC-791] Defense
  3043.       Advanced Research Projects Agency, 1981.
  3044.  
  3045.    [TCP 81]
  3046.  
  3047.       Postel, J. Transmission Control Protocol [RFC-793] Defense
  3048.       Advanced Research Projects Agency, 1981.
  3049.  
  3050.    [TCP Checksum 78]
  3051.  
  3052.       Plummer, W. W. TCP Checksum Function Design. Technical Report,
  3053.       Bolt Beranek and Newman, Inc., 1978.
  3054.  
  3055. EDITORS NOTES
  3056.  
  3057.    This memo was prepared in essentially this form in June 1983, and set
  3058.    aside.  Distribution at this time is prompted by the the "Thinwire"
  3059.    proposal described in RFC-914.
  3060.  
  3061.    --jon postel
  3062.  
  3063.  
  3064.  
  3065.  
  3066.  
  3067.  
  3068.  
  3069.  
  3070.  
  3071.  
  3072.  
  3073.  
  3074.  
  3075.  
  3076.  
  3077. Finn                                                           [Page 54]
  3078.  
  3079.